Re: [PATCH v3] mmc: dw_mmc: Add MSHC compatible for Exynos4412
Hi,
On Tue, Feb 19, 2013 at 6:04 PM, Dongjin Kim wrote:
> Hello Seungwon,
>
> Thank you for reviewing and I understand what you mean.
>
> I agree that Exynos5250 and Exynos4412 are not same, no idea how much
> they are different because no Exynos5250 spec on my hand. But at least
> I assumed that the capabilities below are supported by Exynos4412 in
> terms of its datasheet and it does work on my end as expected. :) Also
> I assumed it will be separated if one of both become different to add
> more capabilities.
>
> MMC_CAP_UHS_DDR50 | MMC_CAP_1_8V_DDR |
>MMC_CAP_8_BIT_DATA | MMC_CAP_CMD23,
>
> Maybe my understanding or approach is wrong since I do not have the
> information of Exynos5250.
> And suggestion do you have?
Recently Guennadi Liakhovetski has done some work to centralize the
mmc capabilities. See [1] and [2].
Those patches are pushed to Chris's mmc-next tree.
Is it possible to extend [1] and [2] and add more capabilities (at
least all known one) and let these caps being passed from DT instead?
Second thought is, let the common minimum caps as a part of .caps
field in dw_mmc-exynos.c itself and pass the extra/advance controller
caps from DT and parse them via dw_mci_parse_dt() in dw_mmc.c itself.
[1] https://patchwork.kernel.org/patch/1991851/
[2] https://patchwork.kernel.org/patch/2106531/
> Regards,
> Dongjin.
>
> On Tue, Feb 19, 2013 at 7:19 PM, Seungwon Jeon wrote:
>> On Tuesday, February 19, 2013, Dongjin Kim wrote:
>>> This patch adds the compatible string for MSHC controller of Exynos4412, and
>>> share the controller specific properties with Exynos5250 since they have
>>> same
>>> features. Its driver data name is changed to exynos_drv_data instead SoC
>>> specific name.
>>
>> It's not actually same.
>> Exynos4412 doesn't have forward compatibilities for Exynos5250.
>> I agree that functionality of exynos_drv_data is common.
>> These functions have been implemented for existing Exynos*.
>> But in case of caps, it can't applied completely.
>> I'm concerning about this.
>>
>> Thanks,
>> Seungwon Jeon
>>>
>>> Cc: Jaehoon Chung
>>> Cc: Sachin Kamat
>>> Signed-off-by: Dongjin Kim
>>> ---
>>> drivers/mmc/host/dw_mmc-exynos.c | 12 +++-
>>> 1 file changed, 7 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/dw_mmc-exynos.c
>>> b/drivers/mmc/host/dw_mmc-exynos.c
>>> index 4d50da6..38cd03c 100644
>>> --- a/drivers/mmc/host/dw_mmc-exynos.c
>>> +++ b/drivers/mmc/host/dw_mmc-exynos.c
>>> @@ -199,8 +199,8 @@ static int dw_mci_exynos_setup_bus(struct dw_mci *host,
>>> return 0;
>>> }
>>>
>>> -/* Exynos5250 controller specific capabilities */
>>> -static unsigned long exynos5250_dwmmc_caps[4] = {
>>> +/* Exynos4412/Exynos5250 controller specific capabilities */
>>> +static unsigned long exynos_dwmmc_caps[4] = {
>>> MMC_CAP_UHS_DDR50 | MMC_CAP_1_8V_DDR |
>>> MMC_CAP_8_BIT_DATA | MMC_CAP_CMD23,
>>> MMC_CAP_CMD23,
>>> @@ -208,8 +208,8 @@ static unsigned long exynos5250_dwmmc_caps[4] = {
>>> MMC_CAP_CMD23,
>>> };
>>>
>>> -static const struct dw_mci_drv_data exynos5250_drv_data = {
>>> - .caps = exynos5250_dwmmc_caps,
>>> +static const struct dw_mci_drv_data exynos_drv_data = {
>>> + .caps = exynos_dwmmc_caps,
>>> .init = dw_mci_exynos_priv_init,
>>> .setup_clock= dw_mci_exynos_setup_clock,
>>> .prepare_command= dw_mci_exynos_prepare_command,
>>> @@ -219,8 +219,10 @@ static const struct dw_mci_drv_data
>>> exynos5250_drv_data = {
>>> };
>>>
>>> static const struct of_device_id dw_mci_exynos_match[] = {
>>> + { .compatible = "samsung,exynos4412-dw-mshc",
>>> + .data = &exynos_drv_data, },
>>> { .compatible = "samsung,exynos5250-dw-mshc",
>>> - .data = &exynos5250_drv_data, },
>>> + .data = &exynos_drv_data, },
>>> {},
>>> };
>>> MODULE_DEVICE_TABLE(of, dw_mci_exynos_match);
>>> --
>>> 1.7.10.4
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Regards,
Alim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Boot failure on Origen board using latest kernel
On Sat, Mar 2, 2013 at 10:26 AM, Sachin Kamat wrote: > Hi Alim, > > On 2 March 2013 10:18, Alim Akhtar wrote: >> Hi Sachin, >> >> Looks like exynos4 is not yet moved to the generic dma binding recently >> merged. >> >> Could you try out below: > > I forgot to mention in the previous mail that the problem was in non-dt case. > With the below entries added in exynos4 dtsi file, it boots fine in DT case. > Aha, I understand. But I think the current mainline kernel is broken for __DT case__ also for exynos4 and that is what my suggested patch fix. Thanks for you confirmation. > -- > With warm regards, > Sachin -- Regards, Alim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 13/13] scsi: ufs: Add exynos ufs platform data
Hi Rob, On Mon, Oct 5, 2015 at 7:41 PM, Rob Herring wrote: > On Mon, Oct 5, 2015 at 4:06 AM, Arnd Bergmann wrote: >> On Monday 05 October 2015 13:44:29 Alim Akhtar wrote: >>> CCing Rob Herring, >>> >>> Hi Arnd, >>> >>> On 10/01/2015 04:59 PM, Arnd Bergmann wrote: >>> > On Thursday 01 October 2015 18:46:34 kbuild test robot wrote: >>> >> [auto build test results on v4.3-rc3 -- if it's inappropriate base, >>> >> please ignore] >>> >> >>> >> config: x86_64-allmodconfig (attached as .config) >>> >> reproduce: >>> >> git checkout 6e153e3bf7c68b019e987c5a0ffadebd9c7d4fbb >>> >> # save the attached .config to linux build tree >>> >> make ARCH=x86_64 >>> >> >>> >> All error/warnings (new ones prefixed by >>): >>> >> >>> >>>> ERROR: "ufs_hba_exynos_ops" [drivers/scsi/ufs/ufshcd-pltfrm.ko] >>> >>>> undefined! >>> >> >>> >> >>> > >>> > Ah, this seems to be a case of layering violation. It would be best to >>> > restructure the code so that the exynos driver registers a platform_driver >>> > by itself for the respective DT compatible string, and then calls >>> > into the common code from its probe function, rather than having the >>> > generic driver know about the specific backends. >>> > >>> > That approach will also make the generic driver more scalable as we >>> > add further chip-specific variations, and matches what we do in other >>> > drivers. >>> > >>> >>> Looks like some discussions on ufs variant driver probe method happened >>> here [1] few months back. >>> [1]-> https://lkml.org/lkml/2015/6/3/180 >> >> Hmm, too bad we didn't catch it then, it's much more work to fix now. > > What you suggested is what is being implemented[1]. It is not merged > yet. The core is a library and the platform specific parts create the > driver. > > Rob > > [1] https://lkml.org/lkml/2015/9/2/364 Thanks for the pointer...let me have a look. At least now we have another variant to test it out. > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Alim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/10] scsi: ufs: add quirk to contain unconformable utrd field
Hi Amit,
Thanks for your review comments.
On 08/26/2015 11:43 AM, amit daniel kachhap wrote:
Few minor comments below,
On Fri, Aug 21, 2015 at 2:57 PM, Alim Akhtar wrote:
From: Seungwon Jeon
UTRD(UTP Transfer Request Descriptor)'s field such as offset/length,
especially response's has DWORD expression. This quirk can be specified
for host controller not to conform standard.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c | 28 +---
drivers/scsi/ufs/ufshcd.h |7 +++
2 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index b0ade73..f882bf0 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1009,7 +1009,7 @@ ufshcd_send_uic_cmd(struct ufs_hba *hba, struct
uic_command *uic_cmd)
*
* Returns 0 in case of success, non-zero value in case of failure
*/
-static int ufshcd_map_sg(struct ufshcd_lrb *lrbp)
+static int ufshcd_map_sg(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
{
struct ufshcd_sg_entry *prd_table;
struct scatterlist *sg;
@@ -1023,8 +1023,13 @@ static int ufshcd_map_sg(struct ufshcd_lrb *lrbp)
return sg_segments;
if (sg_segments) {
- lrbp->utr_descriptor_ptr->prd_table_length =
- cpu_to_le16((u16) (sg_segments));
+ if (hba->quirks & UFSHCI_QUIRK_BROKEN_UTRD)
+ lrbp->utr_descriptor_ptr->prd_table_length =
+ cpu_to_le16((u16)(sg_segments *
+ sizeof(struct ufshcd_sg_entry)));
+ else
+ lrbp->utr_descriptor_ptr->prd_table_length =
+ cpu_to_le16((u16) (sg_segments));
prd_table = (struct ufshcd_sg_entry *)lrbp->ucd_prdt_ptr;
@@ -1347,7 +1352,7 @@ static int ufshcd_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *cmd)
/* form UPIU before issuing the command */
ufshcd_compose_upiu(hba, lrbp);
- err = ufshcd_map_sg(lrbp);
+ err = ufshcd_map_sg(hba, lrbp);
if (err) {
lrbp->cmd = NULL;
clear_bit_unlock(tag, &hba->lrb_in_use);
@@ -2035,12 +2040,21 @@ static void ufshcd_host_memory_configure(struct ufs_hba
*hba)
cpu_to_le32(upper_32_bits(cmd_desc_element_addr));
/* Response upiu and prdt offset should be in double words */
This comment can be moved below for the else case.
ok
- utrdlp[i].response_upiu_offset =
+ if (hba->quirks & UFSHCI_QUIRK_BROKEN_UTRD) {
+ utrdlp[i].response_upiu_offset =
+ cpu_to_le16(response_offset);
+ utrdlp[i].prd_table_offset =
+ cpu_to_le16(prdt_offset);
+ utrdlp[i].response_upiu_length =
+ cpu_to_le16(ALIGNED_UPIU_SIZE);
+ } else {
+ utrdlp[i].response_upiu_offset =
cpu_to_le16((response_offset >> 2));
- utrdlp[i].prd_table_offset =
+ utrdlp[i].prd_table_offset =
cpu_to_le16((prdt_offset >> 2));
- utrdlp[i].response_upiu_length =
+ utrdlp[i].response_upiu_length =
cpu_to_le16(ALIGNED_UPIU_SIZE >> 2);
+ }
hba->lrb[i].utr_descriptor_ptr = (utrdlp + i);
hba->lrb[i].ucd_req_ptr =
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index c40a0e7..1fa5ac1 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -459,6 +459,13 @@ struct ufs_hba {
*/
#define UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION UFS_BIT(5)
+ /*
+* This quirk needs to be enabled if host controller doesn't conform
+* with UTRD. Some fields such as offset/length might not be in double
word,
+* but in byte.
+*/
+ #define UFSHCI_QUIRK_BROKEN_UTRDUFS_BIT(6)
This macro name may be given more meaningful name such as
UFSHCI_QUIRK_BYTE_ALIGN_UTRD or something similar.
ok, will change
+
unsigned int quirks;/* Deviations from standard UFSHCI spec. */
wait_queue_head_t tm_wq;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.ke
Re: [PATCH 01/10] phy: exynos-ufs: add UFS PHY driver for EXYNOS SoC
HI Alexey,
Thanks for review.
I will address your comments in v2 of this patch.
On 08/24/2015 04:15 AM, Alexey Klimov wrote:
Hi Alim,
On Fri, Aug 21, 2015 at 12:27 PM, Alim Akhtar wrote:
From: Seungwon Jeon
This patch introduces Exynos UFS PHY driver. This driver
supports to deal with phy calibration and power control
according to UFS host driver's behavior.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
Cc: Kishon Vijay Abraham I
---
.../devicetree/bindings/phy/samsung-phy.txt| 22 ++
drivers/phy/Kconfig|7 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos-ufs.c | 277
drivers/phy/phy-exynos-ufs.h | 73 ++
drivers/phy/phy-exynos7-ufs.h | 89 +++
include/linux/phy/phy-exynos-ufs.h | 107
7 files changed, 576 insertions(+)
create mode 100644 drivers/phy/phy-exynos-ufs.c
create mode 100644 drivers/phy/phy-exynos-ufs.h
create mode 100644 drivers/phy/phy-exynos7-ufs.h
create mode 100644 include/linux/phy/phy-exynos-ufs.h
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 60c6f2a..1abe2c4 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -174,3 +174,25 @@ Example:
usbdrdphy0 = &usb3_phy0;
usbdrdphy1 = &usb3_phy1;
};
+
+Samsung Exynos7 soc serise UFS PHY Controller
+-
+
+UFS PHY nodes are defined to describe on-chip UFS Physical layer controllers.
+Each UFS PHY controller should have its own node.
+
+Required properties:
+- compatible: compatible list, contains "samsung,exynos7-ufs-phy"
+- reg : offset and length of the UFS PHY register set;
+- reg-names : reg name(s) must be 'phy-pma';
+- #phy-cells : must be zero
+- samsung,syscon-phandle : a phandle to the PMU system controller, no arguments
+
+Example:
+ ufs_phy: ufs-phy@0x15571800 {
+ compatible = "samsung,exynos7-ufs-phy";
+ reg = <0x15571800 0x240>;
+ reg-names = "phy-pma";
+ samsung,syscon-phandle = <&pmu_system_controller>;
+ #phy-cells = <0>;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 6b8dd16..7449376 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -358,4 +358,11 @@ config PHY_BRCMSTB_SATA
Enable this to support the SATA3 PHY on 28nm Broadcom STB SoCs.
Likely useful only with CONFIG_SATA_BRCMSTB enabled.
+config PHY_EXYNOS_UFS
+ tristate "EXYNOS SoC series UFS PHY driver"
+ depends on OF && ARCH_EXYNOS
+ select GENERIC_PHY
+ help
+ Support for UFS PHY on Samsung EXYNOS chipsets.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index f344e1b..7a36818 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -45,3 +45,4 @@ obj-$(CONFIG_PHY_QCOM_UFS)+= phy-qcom-ufs-qmp-14nm.o
obj-$(CONFIG_PHY_TUSB1210) += phy-tusb1210.o
obj-$(CONFIG_PHY_BRCMSTB_SATA) += phy-brcmstb-sata.o
obj-$(CONFIG_PHY_PISTACHIO_USB)+= phy-pistachio-usb.o
+obj-$(CONFIG_PHY_EXYNOS_UFS) += phy-exynos-ufs.o
diff --git a/drivers/phy/phy-exynos-ufs.c b/drivers/phy/phy-exynos-ufs.c
new file mode 100644
index 000..840375d
--- /dev/null
+++ b/drivers/phy/phy-exynos-ufs.c
@@ -0,0 +1,277 @@
+/*
+ * UFS PHY driver for Samsung EXYNOS SoC
+ *
+ * Copyright (C) 2015 Samsung Electronics Co., Ltd.
+ * Author: Seungwon Jeon
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
What do you think about sorting this?
+#include "phy-exynos-ufs.h"
+
+#define for_each_phy_lane(phy, i) \
+ for (i = 0; i < (phy)->lane_cnt; i++)
+#define for_each_phy_cfg(cfg) \
+ for (; (cfg)->id; (cfg)++)
+
+#define phy_pma_writel(phy, val, reg) \
+ writel((val), (phy)->reg_pma + (reg))
+#define phy_pma_readl(phy, reg) \
+ readl((phy)->reg_pma + (reg))
+
+#define PHY_DEF_LANE_CNT 1
+
+static inline struct exynos_ufs_phy *get_exynos_ufs_phy(struct phy *phy)
+{
+ return (struct exynos_ufs_phy *)phy_get_drvdata(phy);
+}
Let compiler decide when to inline static function.
Please don't make static inline functions in *.c files.
Thanks.
--
To unsubscribe from this list: send the line &quo
Re: [PATCH] arm: dts: Fix audio card detection on peach boards
Hi Sylwester,
On 10/12/2015 02:48 PM, Sylwester Nawrocki wrote:
On 12/10/15 08:47, Krzysztof Kozlowski wrote:
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 8f4d76c..525a93a 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -1056,5 +1056,10 @@
timeout-sec = <32>;
};
+&pmu_system_controller {
Please put the node in alphabetical order.
+ assigned-clocks = <&pmu_system_controller 0>;
+ assigned-clock-parents = <&clock CLK_FIN_PLL>;
I might be missing something here but isn't the first clock of
pmu_system_controller already a CLK_FIN_PLL? So you are reparenting the
FIN_PLL to FIN_PLL?
No, it's not, the first PMU consumer clock is indeed CLK_FIN_PLL,
but pmu_system_controller is also a clock provider. The first output
clock of pmu_system_controller is CLKOUT, it's a composite mux and
gate clock (registered in drivers/clk/samsung /clk-exynos-clkout.c).
So the above dts change is selecting an external oscillator input of
the CLKOUT mux, i.e. it will route 24 MHz clock signal from the external
oscillator to the CLKOUT output pin, to which audio CODEC is connected
on peach-pit AFAICS.
Thanks for your explanation, indeed master clock of codec is
connected to XCLKOUT on peach boards.
Will send v2 addressing Kezysztof's other comments.
Regards,
Alim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm: dts: Fix audio card detection on peach boards
Hello Kezysztof
Thanks for your review.
On 10/12/2015 12:17 PM, Krzysztof Kozlowski wrote:
On 12.10.2015 15:26, Alim Akhtar wrote:
Since the merge of 2fad972 ("ARM: dts: Add mclk entry for Peach boards"),
Please switch to longer SHA abbreviation:
$ git config core.abbrev 12
ok, will do thanks
sound card detection is broken on peach boards and gives below errors:
[3.630457] max98090 7-0010: MAX98091 REVID=0x51
[3.634233] max98090 7-0010: use default 2.8v micbias
[3.640985] snow-audio sound: HiFi <-> 383.i2s mapping ok
[3.645307] max98090 7-0010: Invalid master clock frequency
[3.650824] snow-audio sound: ASoC: Peach-Pi-I2S-MAX98091 late_probe()
failed: -22
[3.658914] snow-audio sound: snd_soc_register_card failed (-22)
[3.664366] snow-audio: probe of sound failed with error -22
This patch adds missing assigned-clocks and assigned-clock-parents for
pmu_system_controller node which is used as "mclk" for audio codec.
Signed-off-by: Alim Akhtar
Fixes: 2fad972 ("ARM: dts: Add mclk entry for Peach boards")
Cc:
---
arch/arm/boot/dts/exynos5420-peach-pit.dts |5 +
arch/arm/boot/dts/exynos5800-peach-pi.dts |5 +
2 files changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 8f4d76c..525a93a 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -1056,5 +1056,10 @@
timeout-sec = <32>;
};
+&pmu_system_controller {
Please put the node in alphabetical order.
ok
+ assigned-clocks = <&pmu_system_controller 0>;
+ assigned-clock-parents = <&clock CLK_FIN_PLL>;
I might be missing something here but isn't the first clock of
pmu_system_controller already a CLK_FIN_PLL? So you are reparenting the
FIN_PLL to FIN_PLL?
In the same time there is doubled space character after '='.
will remove
+};
+
#include "cros-ec-keyboard.dtsi"
#include "cros-adc-thermistors.dtsi"
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 7d5b386..411de8f 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -1019,5 +1019,10 @@
timeout-sec = <32>;
};
+&pmu_system_controller {
+ assigned-clocks = <&pmu_system_controller 0>;
+ assigned-clock-parents = <&clock CLK_FIN_PLL>;
Ditto.
Best regards,
Krzysztof
+};
+
#include "cros-ec-keyboard.dtsi"
#include "cros-adc-thermistors.dtsi"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] arm: dts: Fix audio card detection on peach boards
Since commit 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards"),
sound card detection is broken on peach boards and gives below errors:
[3.630457] max98090 7-0010: MAX98091 REVID=0x51
[3.634233] max98090 7-0010: use default 2.8v micbias
[3.640985] snow-audio sound: HiFi <-> 383.i2s mapping ok
[3.645307] max98090 7-0010: Invalid master clock frequency
[3.650824] snow-audio sound: ASoC: Peach-Pi-I2S-MAX98091 late_probe()
failed: -22
[3.658914] snow-audio sound: snd_soc_register_card failed (-22)
[3.664366] snow-audio: probe of sound failed with error -22
This patch adds missing assigned-clocks and assigned-clock-parents for
pmu_system_controller node which is used as "mclk" for audio codec.
Signed-off-by: Alim Akhtar
Fixes: 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards")
Cc:
---
Changes since v1:
Addressed Krzysztof's review comments.
arch/arm/boot/dts/exynos5420-peach-pit.dts |5 +
arch/arm/boot/dts/exynos5800-peach-pi.dts |5 +
2 files changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 8f4d76c5e11c..1b95da79293c 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -915,6 +915,11 @@
};
};
+&pmu_system_controller {
+ assigned-clocks = <&pmu_system_controller 0>;
+ assigned-clock-parents = <&clock CLK_FIN_PLL>;
+};
+
&rtc {
status = "okay";
clocks = <&clock CLK_RTC>, <&max77802 MAX77802_CLK_32K_AP>;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 7d5b386b5ae6..8f40c7e549bd 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -878,6 +878,11 @@
};
};
+&pmu_system_controller {
+ assigned-clocks = <&pmu_system_controller 0>;
+ assigned-clock-parents = <&clock CLK_FIN_PLL>;
+};
+
&rtc {
status = "okay";
clocks = <&clock CLK_RTC>, <&max77802 MAX77802_CLK_32K_AP>;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 12/13] scsi: ufs-exynos: add UFS host support for Exynos SoCs
Hi Arnd,
On 10/01/2015 05:42 PM, Arnd Bergmann wrote:
On Thursday 01 October 2015 13:39:29 Alim Akhtar wrote:
+static int exynos7_ufs_drv_init(struct device *dev, struct exynos_ufs *ufs)
+{
+ int ret;
+ const char *const clks[] = {
+ "mout_sclk_combo_phy_embedded",
+ "top_sclk_phy_fsys1_26m",
+ };
+
These clocks are neither in the binding nor in the example.
ok, I am cleaning this a bit, this will come from DT.
+struct exynos_ufs_drv_data exynos_ufs_drvs[] = {
+{
+ .compatible = "samsung,exynos7-ufs",
+ .uic_attr = &exynos7_uic_attr,
+ .quirks = UFSHCI_QUIRK_BYTE_ALIGN_UTRD |
+ UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR |
+ UFSHCI_QUIRK_BROKEN_HCE |
+ UFSHCI_QUIRK_SKIP_RESET_INTR_AGGR,
+ .opts = EXYNOS_UFS_OPT_HAS_APB_CLK_CTRL |
+ EXYNOS_UFS_OPT_BROKEN_AUTO_CLK_CTRL |
+ EXYNOS_UFS_OPT_BROKEN_RX_SEL_IDX,
+ .drv_init = exynos7_ufs_drv_init,
+ .pre_link = exynos7_ufs_pre_link,
+ .post_link = exynos7_ufs_post_link,
+ .pre_pwr_change = exynos7_ufs_pre_pwr_change,
+ .post_pwr_change= exynos7_ufs_post_pwr_change,
+}, {
+}, };
The indentation is a bit unusual here.
hmm..ok will change
diff --git a/drivers/scsi/ufs/ufs-exynos-hw.h b/drivers/scsi/ufs/ufs-exynos-hw.h
new file mode 100644
index 000..8464ec8
--- /dev/null
+++ b/drivers/scsi/ufs/ufs-exynos-hw.h
@@ -0,0 +1,43 @@
+/*
+ * UFS Host Controller driver for Exynos specific extensions
+ *
+ * Copyright (C) 2014-2015 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef _UFS_EXYNOS_HW_H_
+#define _UFS_EXYNOS_HW_H_
+
+#include "ufs-exynos.h"
+#include "unipro.h"
+
+static struct exynos_ufs_uic_attr exynos7_uic_attr = {
You cannot put 'static' variables into a header file.
will remove
+
+/**
+ * exynos_ufs_auto_ctrl_hcc - HCI core clock control by h/w
+ * Control should be disabled in the below cases
+ * - Before host controller S/W reset
+ * - Access to UFS protector's register
+ */
+static void exynos_ufs_auto_ctrl_hcc(struct exynos_ufs *ufs, bool en)
+{
+ u32 misc = hci_readl(ufs, HCI_MISC);
+
+ if (en)
+ hci_writel(ufs, misc | HCI_CORECLK_CTRL_EN, HCI_MISC);
+ else
+ hci_writel(ufs, misc & ~HCI_CORECLK_CTRL_EN, HCI_MISC);
Does this need a spinlock to ensure the change is done atomically?
will check and if needed will add,
+}
+
+static void exynos_ufs_ctrl_clkstop(struct exynos_ufs *ufs, bool en)
+{
+ u32 ctrl = hci_readl(ufs, HCI_CLKSTOP_CTRL);
+ u32 misc = hci_readl(ufs, HCI_MISC);
+
+ if (en) {
+ hci_writel(ufs, misc | CLK_CTRL_EN_MASK, HCI_MISC);
+ hci_writel(ufs, ctrl | CLK_STOP_MASK, HCI_CLKSTOP_CTRL);
+ } else {
+ hci_writel(ufs, ctrl & ~CLK_STOP_MASK, HCI_CLKSTOP_CTRL);
+ hci_writel(ufs, misc & ~CLK_CTRL_EN_MASK, HCI_MISC);
+ }
same here.
+
+static int exynos_ufs_get_clk_info(struct exynos_ufs *ufs)
+{
+ struct ufs_hba *hba = ufs->hba;
+ struct list_head *head = &hba->clk_list_head;
+ struct ufs_clk_info *clki;
+ u32 pclk_rate;
+ u32 f_min, f_max;
+ u8 div = 0;
+ int ret = 0;
+
+ if (!head || list_empty(head))
+ goto out;
+
+ list_for_each_entry(clki, head, list) {
+ if (!IS_ERR_OR_NULL(clki->clk)) {
+ if (!strcmp(clki->name, "aclk_ufs"))
+ ufs->clk_hci_core = clki->clk;
+ else if (!strcmp(clki->name, "sclk_unipro_apb"))
+ ufs->clk_apb = clki->clk;
+ else if (!strcmp(clki->name, "sclk_unipro_main"))
+ ufs->clk_unipro_main = clki->clk;
+ }
+ }
Using IS_ERR_OR_NULL is normally a bug. Also the list/loop can likely be
replaced with another way to express this.
ok
+ do {
+ delta = h8_time - ktime_us_delta(ktime_get(),
+ ufs->entry_hibern8_t);
+ if (delta <= 0)
+ break;
+
+ us = min_t(s64, delta, USEC_PER_MSEC);
+ if (us >
Re: [PATCH v3 11/13] Documentation: devicetree: ufs: Add DT bindings for exynos UFS host controller
Hi Arnd, On 10/01/2015 05:07 PM, Arnd Bergmann wrote: On Thursday 01 October 2015 13:39:28 Alim Akhtar wrote: From: Seungwon Jeon This adds Exynos Universal Flash Storage (UFS) Host Controller DT bindings. Signed-off-by: Seungwon Jeon Signed-off-by: Alim Akhtar --- .../devicetree/bindings/ufs/ufs-exynos.txt | 93 1 file changed, 93 insertions(+) create mode 100644 Documentation/devicetree/bindings/ufs/ufs-exynos.txt diff --git a/Documentation/devicetree/bindings/ufs/ufs-exynos.txt b/Documentation/devicetree/bindings/ufs/ufs-exynos.txt new file mode 100644 index 000..00df72e --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/ufs-exynos.txt @@ -0,0 +1,93 @@ +* Exynos Universal Flash Storage (UFS) Host Controller + +UFSHC nodes are defined to describe on-chip UFS host controllers. +Each UFS controller instance should have its own node. + +Required properties: +- compatible: compatible name, contains "samsung,exynos7-ufs" +- interrupts: +- reg : This needs a list of all the register ranges, which order they are in and what the respective strings must be. will add the details +- clocks: List of phandle and clock specifier pairs +- clock-names : List of clock input name strings sorted in the same + order as the clocks property. You need to list the names you require here. Also the 'clock specifier' includes the phandle, it's not a pair but just a list of specifiers. ok will add +- ufs,pwr-attr-mode : specifies mode value for power mode change +- ufs,pwr-attr-lane : specifies lane count value for power mode change +- ufs,pwr-attr-gear : specifies gear count value for power mode change +- ufs,pwr-attr-hs-series : specifies HS rate series for power mode change +- ufs,pwr-local-l2-timer : specifies array of local UNIPRO L2 timer values + +- ufs,pwr-remote-l2-timer : specifies array of remote UNIPRO L2 timer values + +- ufs-rx-adv-fine-gran-sup_en : specifies support of fine granularity of MPHY, + this is a boolean property. +- ufs-rx-adv-fine-gran-step : specifies granularity steps of MPHY +- ufs-rx-adv-min-activate-time-cap : specifies rx advanced minimum activate time of MPHY +- ufs-pa-granularity : specifies Granularity for PA_TActivate and PA_Hibern8Time +- ufs-pa-tacctivate : specifies time wake-up remote M-RX +- ufs-pa-hibern8time : specifies minimum time to wait in HIBERN8 state These all require a specification of what the allowed values are and/or the units for the numbers. will update the specifications above + + clocks = <&core 0>, <&ref 0>, <&iface 0>; + clock-names = "core_clk", "ref_clk", "iface_clk"; Better rename them to "core", "ref" and "iface", no point requiring to spell out "clk" here. + ufs,pwr-attr-mode = "FAST"; A string is rather unusual here, what are the allowed values? Could you use a boolean property instead? will update the binding, supported modes are FAST, SLOW, FAST_auto etc, so kept the string for more readability + ufs,pwr-attr-lane = /bits/ 8 <2>; + ufs,pwr-attr-gear = /bits/ 8 <2>; Why the "/bits/ 8" ? I am using of_property_read_u8() to read 8 bit value from property. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] phy: exynos-ufs: exynos_ufs_phy_calibrate() can be static
HI
How I am support to handle this patch? Should I just fix these warnings
in my patch or I just add this as a separate patch on the top of the series?
On 10/01/2015 04:34 PM, kbuild test robot wrote:
Signed-off-by: Fengguang Wu
---
phy-exynos-ufs.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/phy-exynos-ufs.c b/drivers/phy/phy-exynos-ufs.c
index 343fcaf..835ee78 100644
--- a/drivers/phy/phy-exynos-ufs.c
+++ b/drivers/phy/phy-exynos-ufs.c
@@ -66,7 +66,7 @@ static bool match_cfg_to_pwr_mode(u8 desc, u8 required_pwr)
return false;
}
-int exynos_ufs_phy_calibrate(struct phy *phy, enum phy_cfg_tag tag, u8 pwr)
+static int exynos_ufs_phy_calibrate(struct phy *phy, enum phy_cfg_tag tag, u8
pwr)
{
struct exynos_ufs_phy *ufs_phy = get_exynos_ufs_phy(phy);
struct exynos_ufs_phy_cfg **cfgs = ufs_phy->cfg;
@@ -93,14 +93,14 @@ out:
return 0;
}
-void exynos_ufs_phy_set_lane_cnt(struct phy *phy, u8 lane_cnt)
+static void exynos_ufs_phy_set_lane_cnt(struct phy *phy, u8 lane_cnt)
{
struct exynos_ufs_phy *ufs_phy = get_exynos_ufs_phy(phy);
ufs_phy->lane_cnt = lane_cnt;
}
-int exynos_ufs_phy_wait_for_lock_acq(struct phy *phy)
+static int exynos_ufs_phy_wait_for_lock_acq(struct phy *phy)
{
struct exynos_ufs_phy *ufs_phy = get_exynos_ufs_phy(phy);
const unsigned int timeout_us = 10;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 12/13] scsi: ufs-exynos: add UFS host support for Exynos SoCs
On 10/13/2015 05:08 PM, Arnd Bergmann wrote: On Tuesday 13 October 2015 16:49:39 Alim Akhtar wrote: diff --git a/drivers/scsi/ufs/ufs-exynos.h b/drivers/scsi/ufs/ufs-exynos.h new file mode 100644 index 000..58aa714 --- /dev/null +++ b/drivers/scsi/ufs/ufs-exynos.h @@ -0,0 +1,463 @@ +/* + * UFS Host Controller driver for Exynos specific extensions + * + * Copyright (C) 2014-2015 Samsung Electronics Co., Ltd. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ + +#ifndef _UFS_EXYNOS_H_ +#define _UFS_EXYNOS_H_ You have a lot of things in this header that are only used in one of the .c files, so just move them there and make the header as small as possible. hmm..these are mostly the registers defines, will removes the one which are not being used as of now. Do you think I should sill move them to .c file? Yes. No need to remove the unused register definitions, just don't put them into a separate header if they are only used in one place. Ok will do that in v4. Thanks. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
+Doug Hello, AFAIR, dw_mmc host controller does support UHS-I [1], specially SDR50 and SDR104 modes. [1]: http://www.spinics.net/lists/linux-mmc/msg28186.html What I remember is, one need to set "broken-cd" property also in order to make it work because of the vqmmc and vmmc connection on board. I didn't find the link right now, but you can search on the web, there was a long discussion about handling this. Have not checked it recently, so not sure if this got broken somehow. Regards, Alim On Wed, Oct 14, 2015 at 5:29 AM, Krzysztof Kozlowski wrote: > On 14.10.2015 01:27, Anand Moon wrote: >> Hi Krzysztof, >> >> On 13 October 2015 at 09:13, Krzysztof Kozlowski >> wrote: >>> >>> On 13.10.2015 12:08, Anand Moon wrote: Hi Krzysztof, On 13 October 2015 at 05:44, Krzysztof Kozlowski wrote: > On 13.10.2015 00:32, Anand Moon wrote: >> Hi Krzysztof, >> >> On 12 October 2015 at 11:14, Krzysztof Kozlowski >> wrote: >>> On 12.10.2015 00:46, Anand Moon wrote: Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104) >>> >>> This description is not entirely correct. The MMC driver already >>> supports these UHS speeds (you did not any code) so you rather enabled >>> it (description of bindings says "is supported"). >>> >>> You mentioned DDR50 but I don't see respective property below. >>> >>> How do you know that these modes are really supported? I don't know. Can >>> you convince me? >> >> Setting this DDR50 capability give me this error. That's the reason to >> drop this capability. > > But you mentioned it in commit message! "Added support for UHS-I ... > (DDR50)" > > In the same time dropping DDR50 is not an sufficient proof that "SDR50 > and SDR104 are really supported". > These changes are related to the microSD card capabilities. So SDR50 have better frequency over DDR50. On the same Sandisk card. When the card select the capability for DDR50 --- [4.001477] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 5000Hz, actual 5000HZ div = 0) [4.001604] mmc1: new ultra high speed DDR50 SDHC card at address [4.004505] mmcblk0: mmc1: SL32G 29.7 GiB [4.009179] mmcblk0: error -110 sending status command, retrying [4.009271] mmcblk0: error -115 sending stop command, original cmd response 0x900, card status 0x900 [4.009275] mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0 [4.025563] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 40Hz, actual 396825HZ div = 63) [4.067770] Console: switching to colour frame buffer device 274x77 [4.098782] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot req 5000Hz, actual 5000HZ div = 0) [4.099692] mmc1: tried to reset card [4.101332] mmcblk0: p1 p2 When the card select the capability for SDR50 - [ 2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req 1Hz, actual 1HZ div = 0) [ 2.449729] mmc1: new ultra high speed SDR50 SDHC card at address [ 2.455984] mmcblk0: mmc1: SL32G 29.7 GiB [ 2.461743] mmcblk0: p1 p2 Which will relate to better read/write speed. >>> >>> Which is not an answer to my question. To none of my previous questions. >>> >> >> Basically UHS-I capability (sd-uhs-sdr12, sd-uhs-sdr25, sd-uhs-sdr50, >> sd-uhs-sdr104) help tune speed supported for mmc >> >> I have tired to compare the speed on high speed UHS-I vs ultra high >> speed UHS-I using izone utility. >> >> [2.572469] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot >> req 5000Hz, actual 5000HZ div = 0) >> [2.572609] mmc1: new high speed SDHC card at address >> >> Command line used: ./iozone -L64 -S32 -azecwI -+n -r4k -r64k >> -r128k -s10M -i0 -i1 -i2 -f datafile -Rb out.xls >> Output is in kBytes/sec >> Time Resolution = 0.01 seconds. >> Processor cache size set to 32 kBytes. >> Processor cache line size set to 64 bytes. >> File stride size set to 17 * record size. >> random >> random bkwdrecordstride >> kB reclenwrite rewritereadrereadread >> write read rewrite read fwrite frewritefread >> freread >>10240 4 16310 65560 5538 >> 982 >>10240 64 8828018897017994 >> 303 >>10240 128 6269020670020128 >> 1096 >>
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
On Wed, Oct 14, 2015 at 7:22 AM, Krzysztof Kozlowski wrote: > On 14.10.2015 10:40, Jaehoon Chung wrote: >> On 10/14/2015 10:15 AM, Krzysztof Kozlowski wrote: >>> On 14.10.2015 10:06, Alim Akhtar wrote: >>>> +Doug >>>> Hello, >>>> AFAIR, dw_mmc host controller does support UHS-I [1], specially SDR50 >>>> and SDR104 modes. >>>> >>>> [1]: http://www.spinics.net/lists/linux-mmc/msg28186.html >>>> >>>> What I remember is, one need to set "broken-cd" property also in order >>>> to make it work because of the vqmmc and vmmc connection on board. I >>>> didn't find the link right now, but you can search on the web, there >>>> was a long discussion about handling this. >>>> Have not checked it recently, so not sure if this got broken somehow. >>>> >>> >>> Please, don't top post. >>> >>> I am not a SD/MMC specialist (I do not feel enough confident in its >>> internals) but the datasheet for 5422 does not mention UHS. However it >>> mentions "High Speed DDR Mode with 200 MHz clock rate (HS400)". This >>> does not look like UHS... >> >> You're right. It's not UHS mode. it mentions eMMC's HS400 mode. >> UHS and HS400 are difference mode. >> >> eMMC mode are supported >> >>> https://www.sdcard.org/developers/overview/bus_speed/ >>> This of course is not a definite proof that 5422 does not support UHS. I >>> am just saying that I couldn't find any information that *it does*. >> >> Well, I think you want to know whether it supported or not. >> Then you can find the information at User manual. >> In mobile storage part of User manual, it described the overview. >> Mobile storage host supports these specification: >> - Secure Digital memory (SD memory version 3.0) >> - Secure Digital I/O SDIO (SDIO version 3.0) >> - etc... >> >> SD3.0 is supported UHS-I mode. >> If user manual of exynos5422 is mentioned this specification, it should be >> supported UHS-I mode. > > Thanks! Indeed datasheet mentions that supported SD and SDIO is version > 3.0 (not 3.01... which seems irrelevant because 3.0 introduced UHS-I, > right?). > Yes, your understanding is right. SD3.0 does includes UHS-I. > Best regards, > Krzysztof -- Regards, Alim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
On Wed, Oct 14, 2015 at 6:45 AM, Krzysztof Kozlowski wrote: > On 14.10.2015 10:06, Alim Akhtar wrote: >> +Doug >> Hello, >> AFAIR, dw_mmc host controller does support UHS-I [1], specially SDR50 >> and SDR104 modes. >> >> [1]: http://www.spinics.net/lists/linux-mmc/msg28186.html >> >> What I remember is, one need to set "broken-cd" property also in order >> to make it work because of the vqmmc and vmmc connection on board. I >> didn't find the link right now, but you can search on the web, there >> was a long discussion about handling this. >> Have not checked it recently, so not sure if this got broken somehow. >> > > Please, don't top post. > I am sorry, but I didn't get this, what is the guide line here??? > I am not a SD/MMC specialist (I do not feel enough confident in its > internals) but the datasheet for 5422 does not mention UHS. However it > mentions "High Speed DDR Mode with 200 MHz clock rate (HS400)". This > does not look like UHS... > https://www.sdcard.org/developers/overview/bus_speed/ > This of course is not a definite proof that 5422 does not support UHS. I > am just saying that I couldn't find any information that *it does*. > > Best regards, > Krzysztof > -- Regards, Alim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
On Wed, Oct 14, 2015 at 7:50 AM, Krzysztof Kozlowski wrote: > On 14.10.2015 11:13, Alim Akhtar wrote: >> On Wed, Oct 14, 2015 at 6:45 AM, Krzysztof Kozlowski >> wrote: >>> On 14.10.2015 10:06, Alim Akhtar wrote: >>>> +Doug >>>> Hello, >>>> AFAIR, dw_mmc host controller does support UHS-I [1], specially SDR50 >>>> and SDR104 modes. >>>> >>>> [1]: http://www.spinics.net/lists/linux-mmc/msg28186.html >>>> >>>> What I remember is, one need to set "broken-cd" property also in order >>>> to make it work because of the vqmmc and vmmc connection on board. I >>>> didn't find the link right now, but you can search on the web, there >>>> was a long discussion about handling this. >>>> Have not checked it recently, so not sure if this got broken somehow. >>>> >>> >>> Please, don't top post. >>> >> I am sorry, but I didn't get this, what is the guide line here??? > > I mean reply inline, under the other person's quote, not above it. > > And some old, really old joke: > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > > :) > I see..got it..thanks for clarification. > Best regards, > Krzysztof > -- Regards, Alim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 00/11] exynos-ufs: add support for Exynos
This patch-set introduces UFS (Universal Flash Storage) host support for Samsung Exynos SoC. Mostly, it consists of UFS PHY and host specific driver. And it also contains some quirks handling for Exynos. NOTE: ** This series has a dependency on [4]. ** -Changes since v3: * Fixed compilation warrings as reported by "Kbuild Test Robot"[5]. * Restructure the driver to make it as a platform driver, rebased on top of [4]. * Addressed review comments from Arnd Bergmann[5]. * Other misc changes and improvements. -Changes since v2: * Addressed review comments from Kishon[1] and Rob Herring [2] * Splited ufs dt binding documetation from ufs driver patch -Changes since v1: * Addressed review comments from Alexey[3] and various review comments from Amit. * Updated email id of Seungwon as his samsung id is void now. * Added ufs platform data [1]-> https://lkml.org/lkml/2015/9/18/29 [2]-> https://lkml.org/lkml/2015/9/21/668 [3]-> https://lkml.org/lkml/2015/8/23/124 [4]-> https://lkml.org/lkml/2015/9/2/364 [5]-> https://lkml.org/lkml/2015/10/1/402 This patch set is tested on exynos7-espresso board. Alim Akhtar (1): Documentation: samsung-phy: Add dt bindings for UFS Seungwon Jeon (10): phy: exynos-ufs: add UFS PHY driver for EXYNOS SoC scsi: ufs: add quirk to contain unconformable utrd field scsi: ufs: add quirk to fix mishandling utrlclr/utmrlclr scsi: ufs: add quirk not to allow reset of interrupt aggregation scsi: ufs: add quirk to enable host controller without hce scsi: ufs: add specific callback for nexus type scsi: ufs: add add specific callback for hibern8 scsi: ufs: make ufshcd_config_pwr_mode of non-static func Documentation: devicetree: ufs: Add DT bindings for exynos UFS host controller scsi: ufs-exynos: add UFS host support for Exynos SoCs .../devicetree/bindings/phy/samsung-phy.txt| 22 + .../devicetree/bindings/ufs/ufs-exynos.txt | 104 ++ drivers/phy/Kconfig|7 + drivers/phy/Makefile |1 + drivers/phy/phy-exynos-ufs.c | 257 drivers/phy/phy-exynos-ufs.h | 88 ++ drivers/phy/phy-exynos7-ufs.h | 89 ++ drivers/scsi/ufs/Kconfig | 12 + drivers/scsi/ufs/Makefile |1 + drivers/scsi/ufs/ufs-exynos-hw.c | 131 ++ drivers/scsi/ufs/ufs-exynos-hw.h | 43 + drivers/scsi/ufs/ufs-exynos.c | 1317 drivers/scsi/ufs/ufs-exynos.h | 247 drivers/scsi/ufs/ufshcd.c | 168 ++- drivers/scsi/ufs/ufshcd.h | 54 + drivers/scsi/ufs/ufshci.h | 26 +- drivers/scsi/ufs/unipro.h | 47 + include/linux/phy/phy-exynos-ufs.h | 101 ++ 18 files changed, 2695 insertions(+), 20 deletions(-) create mode 100644 Documentation/devicetree/bindings/ufs/ufs-exynos.txt create mode 100644 drivers/phy/phy-exynos-ufs.c create mode 100644 drivers/phy/phy-exynos-ufs.h create mode 100644 drivers/phy/phy-exynos7-ufs.h create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.c create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.h create mode 100644 drivers/scsi/ufs/ufs-exynos.c create mode 100644 drivers/scsi/ufs/ufs-exynos.h create mode 100644 include/linux/phy/phy-exynos-ufs.h -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 01/11] Documentation: samsung-phy: Add dt bindings for UFS
Adds exynos UFS PHY device tree bindings information.
Signed-off-by: Alim Akhtar
---
.../devicetree/bindings/phy/samsung-phy.txt| 22
1 file changed, 22 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 60c6f2a633e0..c92ce537ceec 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -174,3 +174,25 @@ Example:
usbdrdphy0 = &usb3_phy0;
usbdrdphy1 = &usb3_phy1;
};
+
+Samsung Exynos7 soc series UFS PHY Controller
+-
+
+UFS PHY nodes are defined to describe on-chip UFS Physical layer controllers.
+Each UFS PHY controller should have its own node.
+
+Required properties:
+- compatible: compatible should be set to "samsung,exynos7-ufs-phy"
+- reg : offset and length of the UFS PHY register set
+- reg-names : reg name(s) must be 'phy-pma'
+- #phy-cells : must be zero
+- samsung,pmu-syscon : a phandle to the PMU system controller, no arguments
+
+Example:
+ ufs_phy: ufs-phy@0x15571800 {
+ compatible = "samsung,exynos7-ufs-phy";
+ reg = <0x15571800 0x240>;
+ reg-names = "phy-pma";
+ samsung,pmu-syscon = <&pmu_system_controller>;
+ #phy-cells = <0>;
+ };
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 02/11] phy: exynos-ufs: add UFS PHY driver for EXYNOS SoC
From: Seungwon Jeon
This patch introduces Exynos UFS PHY driver. This driver
supports to deal with phy calibration and power control
according to UFS host driver's behavior.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
Cc: Kishon Vijay Abraham I
---
drivers/phy/Kconfig|7 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos-ufs.c | 257
drivers/phy/phy-exynos-ufs.h | 88
drivers/phy/phy-exynos7-ufs.h | 89 +
include/linux/phy/phy-exynos-ufs.h | 101 ++
6 files changed, 543 insertions(+)
create mode 100644 drivers/phy/phy-exynos-ufs.c
create mode 100644 drivers/phy/phy-exynos-ufs.h
create mode 100644 drivers/phy/phy-exynos7-ufs.h
create mode 100644 include/linux/phy/phy-exynos-ufs.h
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 47da573d0bab..499eec4a967c 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -371,4 +371,11 @@ config PHY_BRCMSTB_SATA
Enable this to support the SATA3 PHY on 28nm Broadcom STB SoCs.
Likely useful only with CONFIG_SATA_BRCMSTB enabled.
+config PHY_EXYNOS_UFS
+ tristate "EXYNOS SoC series UFS PHY driver"
+ depends on OF && ARCH_EXYNOS || COMPILE_TEST
+ select GENERIC_PHY
+ help
+ Support for UFS PHY on Samsung EXYNOS chipsets.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index a5b18c18fc12..2a312ca20795 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -46,3 +46,4 @@ obj-$(CONFIG_PHY_QCOM_UFS)+= phy-qcom-ufs-qmp-14nm.o
obj-$(CONFIG_PHY_TUSB1210) += phy-tusb1210.o
obj-$(CONFIG_PHY_BRCMSTB_SATA) += phy-brcmstb-sata.o
obj-$(CONFIG_PHY_PISTACHIO_USB)+= phy-pistachio-usb.o
+obj-$(CONFIG_PHY_EXYNOS_UFS) += phy-exynos-ufs.o
diff --git a/drivers/phy/phy-exynos-ufs.c b/drivers/phy/phy-exynos-ufs.c
new file mode 100644
index ..77330b85e3f8
--- /dev/null
+++ b/drivers/phy/phy-exynos-ufs.c
@@ -0,0 +1,257 @@
+/*
+ * UFS PHY driver for Samsung EXYNOS SoC
+ *
+ * Copyright (C) 2015 Samsung Electronics Co., Ltd.
+ * Author: Seungwon Jeon
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "phy-exynos-ufs.h"
+
+#define for_each_phy_lane(phy, i) \
+ for (i = 0; i < (phy)->lane_cnt; i++)
+#define for_each_phy_cfg(cfg) \
+ for (; (cfg)->id; (cfg)++)
+
+#define PHY_DEF_LANE_CNT 1
+
+static void exynos_ufs_phy_config(struct exynos_ufs_phy *phy,
+ const struct exynos_ufs_phy_cfg *cfg, u8 lane)
+{
+ enum {LANE_0, LANE_1}; /* lane index */
+
+ switch (lane) {
+ case LANE_0:
+ writel(cfg->val, (phy)->reg_pma + cfg->off_0);
+ break;
+ case LANE_1:
+ if (cfg->id == PHY_TRSV_BLK)
+ writel(cfg->val, (phy)->reg_pma + cfg->off_1);
+ break;
+ }
+}
+
+static bool match_cfg_to_pwr_mode(u8 desc, u8 required_pwr)
+{
+ if (IS_PWR_MODE_ANY(desc))
+ return true;
+
+ if (IS_PWR_MODE_HS(required_pwr) && IS_PWR_MODE_HS_ANY(desc))
+ return true;
+
+ if (COMP_PWR_MODE(required_pwr, desc))
+ return true;
+
+ if (COMP_PWR_MODE_MD(required_pwr, desc) &&
+ COMP_PWR_MODE_GEAR(required_pwr, desc) &&
+ COMP_PWR_MODE_SER(required_pwr, desc))
+ return true;
+
+ return false;
+}
+
+static int exynos_ufs_phy_calibrate(struct phy *phy,
+ enum phy_cfg_tag tag, u8 pwr)
+{
+ struct exynos_ufs_phy *ufs_phy = get_exynos_ufs_phy(phy);
+ struct exynos_ufs_phy_cfg **cfgs = ufs_phy->cfg;
+ const struct exynos_ufs_phy_cfg *cfg;
+ int i;
+
+ if (unlikely(tag < CFG_PRE_INIT || tag >= CFG_TAG_MAX)) {
+ dev_err(ufs_phy->dev, "invalid phy config index %d\n", tag);
+ return -EINVAL;
+ }
+
+ cfg = cfgs[tag];
+ if (!cfg)
+ goto out;
+
+ for_each_phy_cfg(cfg) {
+ for_each_phy_lane(ufs_phy, i) {
+ if (match_cfg_to_pwr_mode(cfg->desc, pwr))
+ exynos_ufs_phy_config(ufs_phy, cfg, i);
+ }
+ }
+
+out:
+ return 0;
+}
+
+static void exynos_ufs_phy_set_lane_cnt(struct phy *phy, u8 lane_cnt)
+{
+ struct exynos_ufs_phy *ufs_phy = get_exynos_ufs_phy(phy);
+
+ ufs_phy->lane_cnt = lan
[PATCH v4 04/11] scsi: ufs: add quirk to fix mishandling utrlclr/utmrlclr
From: Seungwon Jeon
In the right behavior, setting the bit to '0' indicates clear and
'1' indicates no change. If host contoller handles this the other way,
UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR can be used.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c | 21 +++--
drivers/scsi/ufs/ufshcd.h |5 +
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 587a9c8fbfe9..2b16eb363203 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -356,7 +356,24 @@ static inline void ufshcd_put_tm_slot(struct ufs_hba *hba,
int slot)
*/
static inline void ufshcd_utrl_clear(struct ufs_hba *hba, u32 pos)
{
- ufshcd_writel(hba, ~(1 << pos), REG_UTP_TRANSFER_REQ_LIST_CLEAR);
+ if (hba->quirks & UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR)
+ ufshcd_writel(hba, (1 << pos), REG_UTP_TRANSFER_REQ_LIST_CLEAR);
+ else
+ ufshcd_writel(hba, ~(1 << pos),
+ REG_UTP_TRANSFER_REQ_LIST_CLEAR);
+}
+
+/**
+ * ufshcd_utmrl_clear - Clear a bit in UTRMLCLR register
+ * @hba: per adapter instance
+ * @pos: position of the bit to be cleared
+ */
+static inline void ufshcd_utmrl_clear(struct ufs_hba *hba, u32 pos)
+{
+ if (hba->quirks & UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR)
+ ufshcd_writel(hba, (1 << pos), REG_UTP_TASK_REQ_LIST_CLEAR);
+ else
+ ufshcd_writel(hba, ~(1 << pos), REG_UTP_TASK_REQ_LIST_CLEAR);
}
/**
@@ -3685,7 +3702,7 @@ static int ufshcd_clear_tm_cmd(struct ufs_hba *hba, int
tag)
goto out;
spin_lock_irqsave(hba->host->host_lock, flags);
- ufshcd_writel(hba, ~(1 << tag), REG_UTP_TASK_REQ_LIST_CLEAR);
+ ufshcd_utmrl_clear(hba, tag);
spin_unlock_irqrestore(hba->host->host_lock, flags);
/* poll for max. 1 sec to clear door bell register by h/w */
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 6cd542a803d5..d625d01110b0 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -474,6 +474,11 @@ struct ufs_hba {
*/
#define UFSHCI_QUIRK_BYTE_ALIGN_UTRDUFS_BIT(6)
+ /*
+* Cleaer handling for transfer/task request list is just opposite.
+*/
+ #define UFSHCI_QUIRK_BROKEN_REQ_LIST_CLRUFS_BIT(7)
+
unsigned int quirks;/* Deviations from standard UFSHCI spec. */
wait_queue_head_t tm_wq;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 03/11] scsi: ufs: add quirk to contain unconformable utrd field
From: Seungwon Jeon
UTRD(UTP Transfer Request Descriptor)'s field such as offset/length,
especially response's has DWORD expression. This quirk can be specified
for host controller not to conform standard.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c | 28 +---
drivers/scsi/ufs/ufshcd.h |7 +++
2 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 131c72038bf8..587a9c8fbfe9 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1009,7 +1009,7 @@ ufshcd_send_uic_cmd(struct ufs_hba *hba, struct
uic_command *uic_cmd)
*
* Returns 0 in case of success, non-zero value in case of failure
*/
-static int ufshcd_map_sg(struct ufshcd_lrb *lrbp)
+static int ufshcd_map_sg(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
{
struct ufshcd_sg_entry *prd_table;
struct scatterlist *sg;
@@ -1023,8 +1023,13 @@ static int ufshcd_map_sg(struct ufshcd_lrb *lrbp)
return sg_segments;
if (sg_segments) {
- lrbp->utr_descriptor_ptr->prd_table_length =
- cpu_to_le16((u16) (sg_segments));
+ if (hba->quirks & UFSHCI_QUIRK_BYTE_ALIGN_UTRD)
+ lrbp->utr_descriptor_ptr->prd_table_length =
+ cpu_to_le16((u16)(sg_segments *
+ sizeof(struct ufshcd_sg_entry)));
+ else
+ lrbp->utr_descriptor_ptr->prd_table_length =
+ cpu_to_le16((u16) (sg_segments));
prd_table = (struct ufshcd_sg_entry *)lrbp->ucd_prdt_ptr;
@@ -1347,7 +1352,7 @@ static int ufshcd_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *cmd)
/* form UPIU before issuing the command */
ufshcd_compose_upiu(hba, lrbp);
- err = ufshcd_map_sg(lrbp);
+ err = ufshcd_map_sg(hba, lrbp);
if (err) {
lrbp->cmd = NULL;
clear_bit_unlock(tag, &hba->lrb_in_use);
@@ -2034,13 +2039,22 @@ static void ufshcd_host_memory_configure(struct ufs_hba
*hba)
utrdlp[i].command_desc_base_addr_hi =
cpu_to_le32(upper_32_bits(cmd_desc_element_addr));
+ if (hba->quirks & UFSHCI_QUIRK_BYTE_ALIGN_UTRD) {
+ utrdlp[i].response_upiu_offset =
+ cpu_to_le16(response_offset);
+ utrdlp[i].prd_table_offset =
+ cpu_to_le16(prdt_offset);
+ utrdlp[i].response_upiu_length =
+ cpu_to_le16(ALIGNED_UPIU_SIZE);
+ } else {
/* Response upiu and prdt offset should be in double words */
- utrdlp[i].response_upiu_offset =
+ utrdlp[i].response_upiu_offset =
cpu_to_le16((response_offset >> 2));
- utrdlp[i].prd_table_offset =
+ utrdlp[i].prd_table_offset =
cpu_to_le16((prdt_offset >> 2));
- utrdlp[i].response_upiu_length =
+ utrdlp[i].response_upiu_length =
cpu_to_le16(ALIGNED_UPIU_SIZE >> 2);
+ }
hba->lrb[i].utr_descriptor_ptr = (utrdlp + i);
hba->lrb[i].ucd_req_ptr =
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 2570d9477b37..6cd542a803d5 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -467,6 +467,13 @@ struct ufs_hba {
*/
#define UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION UFS_BIT(5)
+ /*
+* This quirk needs to be enabled if host controller doesn't conform
+* with UTRD. Some fields such as offset/length might not be in double
+* word, but in byte.
+*/
+ #define UFSHCI_QUIRK_BYTE_ALIGN_UTRDUFS_BIT(6)
+
unsigned int quirks;/* Deviations from standard UFSHCI spec. */
wait_queue_head_t tm_wq;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 05/11] scsi: ufs: add quirk not to allow reset of interrupt aggregation
From: Seungwon Jeon
Some host controller supports interrupt aggregation, but doesn't
allow to reset counter and timer by s/w.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c |3 ++-
drivers/scsi/ufs/ufshcd.h |6 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 2b16eb363203..ca7483cd899e 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -3199,7 +3199,8 @@ static void ufshcd_transfer_req_compl(struct ufs_hba *hba)
* false interrupt if device completes another request after resetting
* aggregation and before reading the DB.
*/
- if (ufshcd_is_intr_aggr_allowed(hba))
+ if (ufshcd_is_intr_aggr_allowed(hba) &&
+ !(hba->quirks & UFSHCI_QUIRK_SKIP_RESET_INTR_AGGR))
ufshcd_reset_intr_aggr(hba);
tr_doorbell = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index d625d01110b0..4ae32e9316de 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -479,6 +479,12 @@ struct ufs_hba {
*/
#define UFSHCI_QUIRK_BROKEN_REQ_LIST_CLRUFS_BIT(7)
+ /*
+* This quirk needs to be enabled if host controller doesn't allow
+* that the interrupt aggregation timer and counter are reset by s/w.
+*/
+ #define UFSHCI_QUIRK_SKIP_RESET_INTR_AGGR UFS_BIT(8)
+
unsigned int quirks;/* Deviations from standard UFSHCI spec. */
wait_queue_head_t tm_wq;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 06/11] scsi: ufs: add quirk to enable host controller without hce
From: Seungwon Jeon
Some host controller doesn't support host controller enable via HCE.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c | 75 +++--
drivers/scsi/ufs/ufshcd.h |5 +++
2 files changed, 78 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index ca7483cd899e..e8b96ec65987 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -2107,6 +2107,52 @@ static int ufshcd_dme_link_startup(struct ufs_hba *hba)
"dme-link-startup: error code %d\n", ret);
return ret;
}
+/**
+ * ufshcd_dme_reset - UIC command for DME_RESET
+ * @hba: per adapter instance
+ *
+ * DME_RESET command is issued in order to reset UniPro stack.
+ * This function now deal with cold reset.
+ *
+ * Returns 0 on success, non-zero value on failure
+ */
+static int ufshcd_dme_reset(struct ufs_hba *hba)
+{
+ struct uic_command uic_cmd = {0};
+ int ret;
+
+ uic_cmd.command = UIC_CMD_DME_RESET;
+
+ ret = ufshcd_send_uic_cmd(hba, &uic_cmd);
+ if (ret)
+ dev_err(hba->dev,
+ "dme-reset: error code %d\n", ret);
+
+ return ret;
+}
+
+/**
+ * ufshcd_dme_enable - UIC command for DME_ENABLE
+ * @hba: per adapter instance
+ *
+ * DME_ENABLE command is issued in order to enable UniPro stack.
+ *
+ * Returns 0 on success, non-zero value on failure
+ */
+static int ufshcd_dme_enable(struct ufs_hba *hba)
+{
+ struct uic_command uic_cmd = {0};
+ int ret;
+
+ uic_cmd.command = UIC_CMD_DME_ENABLE;
+
+ ret = ufshcd_send_uic_cmd(hba, &uic_cmd);
+ if (ret)
+ dev_err(hba->dev,
+ "dme-reset: error code %d\n", ret);
+
+ return ret;
+}
static inline void ufshcd_add_delay_before_dme_cmd(struct ufs_hba *hba)
{
@@ -2642,7 +2688,7 @@ out:
}
/**
- * ufshcd_hba_enable - initialize the controller
+ * ufshcd_hba_execute_hce - initialize the controller
* @hba: per adapter instance
*
* The controller resets itself and controller firmware initialization
@@ -2651,7 +2697,7 @@ out:
*
* Returns 0 on success, non-zero value on failure
*/
-static int ufshcd_hba_enable(struct ufs_hba *hba)
+static int ufshcd_hba_execute_hce(struct ufs_hba *hba)
{
int retry;
@@ -2715,6 +2761,31 @@ static int ufshcd_hba_enable(struct ufs_hba *hba)
return 0;
}
+static int ufshcd_hba_enable(struct ufs_hba *hba)
+{
+ int ret;
+
+ if (hba->quirks & UFSHCI_QUIRK_BROKEN_HCE) {
+ ufshcd_set_link_off(hba);
+ ufshcd_vops_hce_enable_notify(hba, PRE_CHANGE);
+
+ /* enable UIC related interrupts */
+ ufshcd_enable_intr(hba, UFSHCD_UIC_MASK);
+ ret = ufshcd_dme_reset(hba);
+ if (!ret) {
+ ret = ufshcd_dme_enable(hba);
+ if (!ret)
+ ufshcd_vops_hce_enable_notify(hba, POST_CHANGE);
+ if (ret)
+ dev_err(hba->dev,
+ "Host controller enable failed with
non-hce\n");
+ }
+ } else {
+ ret = ufshcd_hba_execute_hce(hba);
+ }
+
+ return ret;
+}
static int ufshcd_disable_tx_lcc(struct ufs_hba *hba, bool peer)
{
int tx_lanes, i, err = 0;
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 4ae32e9316de..500e137bf68a 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -485,6 +485,11 @@ struct ufs_hba {
*/
#define UFSHCI_QUIRK_SKIP_RESET_INTR_AGGR UFS_BIT(8)
+ /*
+* This quirks needs to be enabled if host controller cannot be
+* enabled via HCE register.
+*/
+ #define UFSHCI_QUIRK_BROKEN_HCE UFS_BIT(9)
unsigned int quirks;/* Deviations from standard UFSHCI spec. */
wait_queue_head_t tm_wq;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 07/11] scsi: ufs: add specific callback for nexus type
From: Seungwon Jeon
Some host controller needs nexus type information for handling
command. This change adds specific callback function to support
vendor's implementation.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c |3 +++
drivers/scsi/ufs/ufshcd.h | 19 +++
2 files changed, 22 insertions(+)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index e8b96ec65987..eeb7835c52ab 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1378,6 +1378,7 @@ static int ufshcd_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *cmd)
/* issue command to the controller */
spin_lock_irqsave(hba->host->host_lock, flags);
+ ufshcd_vops_specify_nexus_t_xfer_req(hba, tag, lrbp);
ufshcd_send_command(hba, tag);
out_unlock:
spin_unlock_irqrestore(hba->host->host_lock, flags);
@@ -1578,6 +1579,7 @@ static int ufshcd_exec_dev_cmd(struct ufs_hba *hba,
hba->dev_cmd.complete = &wait;
spin_lock_irqsave(hba->host->host_lock, flags);
+ ufshcd_vops_specify_nexus_t_xfer_req(hba, tag, lrbp);
ufshcd_send_command(hba, tag);
spin_unlock_irqrestore(hba->host->host_lock, flags);
@@ -3842,6 +3844,7 @@ static int ufshcd_issue_tm_cmd(struct ufs_hba *hba, int
lun_id, int task_id,
task_req_upiup->input_param2 = cpu_to_be32(task_id);
/* send command to the controller */
+ ufshcd_vops_specify_nexus_t_tm_req(hba, free_slot, tm_function);
__set_bit(free_slot, &hba->outstanding_tasks);
ufshcd_writel(hba, 1 << free_slot, REG_UTP_TASK_REQ_DOOR_BELL);
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 500e137bf68a..b3dd08420100 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -259,6 +259,9 @@ struct ufs_pwr_mode_info {
* @pwr_change_notify: called before and after a power mode change
* is carried out to allow vendor spesific capabilities
* to be set.
+ * @specify_nexus_t_xfer_req:
+ * @specify_nexus_t_tm_req: called before command is issued to allow vendor
+ * specific handling to be set for nexus type.
* @suspend: called during host controller PM callback
* @resume: called during host controller PM callback
* @dbg_register_dump: used to dump controller debug information
@@ -280,6 +283,9 @@ struct ufs_hba_variant_ops {
enum ufs_notify_change_status status,
struct ufs_pa_layer_attr *,
struct ufs_pa_layer_attr *);
+ void(*specify_nexus_t_xfer_req)(struct ufs_hba *,
+ int, struct scsi_cmnd *);
+ void(*specify_nexus_t_tm_req)(struct ufs_hba *, int, u8);
int (*suspend)(struct ufs_hba *, enum ufs_pm_op);
int (*resume)(struct ufs_hba *, enum ufs_pm_op);
void(*dbg_register_dump)(struct ufs_hba *hba);
@@ -811,4 +817,17 @@ static inline void ufshcd_vops_dbg_register_dump(struct
ufs_hba *hba)
hba->vops->dbg_register_dump(hba);
}
+static inline void ufshcd_vops_specify_nexus_t_xfer_req(struct ufs_hba *hba,
+ int tag, struct ufshcd_lrb *lrbp)
+{
+ if (hba->vops && hba->vops->specify_nexus_t_xfer_req)
+ hba->vops->specify_nexus_t_xfer_req(hba, tag, lrbp->cmd);
+}
+
+static inline void ufshcd_vops_specify_nexus_t_tm_req(struct ufs_hba *hba,
+ int free_slot, u8 tm_function)
+{
+ if (hba->vops && hba->vops->specify_nexus_t_tm_req)
+ hba->vops->specify_nexus_t_tm_req(hba, free_slot, tm_function);
+}
#endif /* End of Header */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 08/11] scsi: ufs: add add specific callback for hibern8
From: Seungwon Jeon
Some host controller needs specific handling before/after
(un)hibernation, This change adds specific callback function
to support vendor's implementation.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c | 33 +
drivers/scsi/ufs/ufshcd.h | 10 ++
2 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index eeb7835c52ab..075b7bf13080 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -181,8 +181,7 @@ static int ufshcd_probe_hba(struct ufs_hba *hba);
static int __ufshcd_setup_clocks(struct ufs_hba *hba, bool on,
bool skip_ref_clk);
static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on);
-static int ufshcd_uic_hibern8_exit(struct ufs_hba *hba);
-static int ufshcd_uic_hibern8_enter(struct ufs_hba *hba);
+static int ufshcd_uic_hibern8_ctrl(struct ufs_hba *hba, bool en);
static inline void ufshcd_add_delay_before_dme_cmd(struct ufs_hba *hba);
static int ufshcd_host_reset_and_restore(struct ufs_hba *hba);
static irqreturn_t ufshcd_intr(int irq, void *__hba);
@@ -215,6 +214,16 @@ static inline void ufshcd_disable_irq(struct ufs_hba *hba)
}
}
+static inline int ufshcd_uic_hibern8_enter(struct ufs_hba *hba)
+{
+ return ufshcd_uic_hibern8_ctrl(hba, true);
+}
+
+static inline int ufshcd_uic_hibern8_exit(struct ufs_hba *hba)
+{
+ return ufshcd_uic_hibern8_ctrl(hba, false);
+}
+
/*
* ufshcd_wait_for_register - wait for register value to change
* @hba - per-adapter interface
@@ -2394,7 +2403,7 @@ out:
return ret;
}
-static int ufshcd_uic_hibern8_enter(struct ufs_hba *hba)
+static int __ufshcd_uic_hibern8_enter(struct ufs_hba *hba)
{
struct uic_command uic_cmd = {0};
@@ -2403,7 +2412,7 @@ static int ufshcd_uic_hibern8_enter(struct ufs_hba *hba)
return ufshcd_uic_pwr_ctrl(hba, &uic_cmd);
}
-static int ufshcd_uic_hibern8_exit(struct ufs_hba *hba)
+static int __ufshcd_uic_hibern8_exit(struct ufs_hba *hba)
{
struct uic_command uic_cmd = {0};
int ret;
@@ -2418,6 +2427,22 @@ static int ufshcd_uic_hibern8_exit(struct ufs_hba *hba)
return ret;
}
+static int ufshcd_uic_hibern8_ctrl(struct ufs_hba *hba, bool en)
+{
+ int ret;
+
+ ufshcd_vops_hibern8_notify(hba, en, PRE_CHANGE);
+ ret = en ? __ufshcd_uic_hibern8_enter(hba) :
+ __ufshcd_uic_hibern8_exit(hba);
+ if (ret)
+ goto out;
+
+ ufshcd_vops_hibern8_notify(hba, en, POST_CHANGE);
+
+out:
+ return ret;
+}
+
/**
* ufshcd_init_pwr_info - setting the POR (power on reset)
* values in hba power info
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index b3dd08420100..9c69dd2f3672 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -262,6 +262,8 @@ struct ufs_pwr_mode_info {
* @specify_nexus_t_xfer_req:
* @specify_nexus_t_tm_req: called before command is issued to allow vendor
* specific handling to be set for nexus type.
+ * @hibern8_notify: called before and after hibernate/unhibernate is carried
out
+ * to allow vendor spesific implementation.
* @suspend: called during host controller PM callback
* @resume: called during host controller PM callback
* @dbg_register_dump: used to dump controller debug information
@@ -283,6 +285,7 @@ struct ufs_hba_variant_ops {
enum ufs_notify_change_status status,
struct ufs_pa_layer_attr *,
struct ufs_pa_layer_attr *);
+ void(*hibern8_notify)(struct ufs_hba *, bool, bool);
void(*specify_nexus_t_xfer_req)(struct ufs_hba *,
int, struct scsi_cmnd *);
void(*specify_nexus_t_tm_req)(struct ufs_hba *, int, u8);
@@ -830,4 +833,11 @@ static inline void
ufshcd_vops_specify_nexus_t_tm_req(struct ufs_hba *hba,
if (hba->vops && hba->vops->specify_nexus_t_tm_req)
hba->vops->specify_nexus_t_tm_req(hba, free_slot, tm_function);
}
+
+static inline void ufshcd_vops_hibern8_notify(struct ufs_hba *hba,
+ bool en, enum ufs_notify_change_status status)
+{
+ if (hba->vops && hba->vops->hibern8_notify)
+ hba->vops->hibern8_notify(hba, en, status);
+}
#endif /* End of Header */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 09/11] scsi: ufs: make ufshcd_config_pwr_mode of non-static func
From: Seungwon Jeon
This makes ufshcd_config_pwr_mode non-static so that other vendors
like exynos can use the same.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c |5 ++---
drivers/scsi/ufs/ufshcd.h |2 ++
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 075b7bf13080..358d9114a1a5 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -185,8 +185,6 @@ static int ufshcd_uic_hibern8_ctrl(struct ufs_hba *hba,
bool en);
static inline void ufshcd_add_delay_before_dme_cmd(struct ufs_hba *hba);
static int ufshcd_host_reset_and_restore(struct ufs_hba *hba);
static irqreturn_t ufshcd_intr(int irq, void *__hba);
-static int ufshcd_config_pwr_mode(struct ufs_hba *hba,
- struct ufs_pa_layer_attr *desired_pwr_mode);
static int ufshcd_change_power_mode(struct ufs_hba *hba,
struct ufs_pa_layer_attr *pwr_mode);
@@ -2592,7 +2590,7 @@ static int ufshcd_change_power_mode(struct ufs_hba *hba,
* @hba: per-adapter instance
* @desired_pwr_mode: desired power configuration
*/
-static int ufshcd_config_pwr_mode(struct ufs_hba *hba,
+int ufshcd_config_pwr_mode(struct ufs_hba *hba,
struct ufs_pa_layer_attr *desired_pwr_mode)
{
struct ufs_pa_layer_attr final_params = { 0 };
@@ -2608,6 +2606,7 @@ static int ufshcd_config_pwr_mode(struct ufs_hba *hba,
return ret;
}
+EXPORT_SYMBOL_GPL(ufshcd_config_pwr_mode);
/**
* ufshcd_complete_dev_init() - checks device readiness
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 9c69dd2f3672..8cad52c072d4 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -666,6 +666,8 @@ extern int ufshcd_dme_set_attr(struct ufs_hba *hba, u32
attr_sel,
u8 attr_set, u32 mib_val, u8 peer);
extern int ufshcd_dme_get_attr(struct ufs_hba *hba, u32 attr_sel,
u32 *mib_val, u8 peer);
+extern int ufshcd_config_pwr_mode(struct ufs_hba *hba,
+ struct ufs_pa_layer_attr *desired_pwr_mode);
/* UIC command interfaces for DME primitives */
#define DME_LOCAL 0
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 10/11] Documentation: devicetree: ufs: Add DT bindings for exynos UFS host controller
From: Seungwon Jeon
This adds Exynos Universal Flash Storage (UFS) Host Controller DT bindings.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
.../devicetree/bindings/ufs/ufs-exynos.txt | 104
1 file changed, 104 insertions(+)
create mode 100644 Documentation/devicetree/bindings/ufs/ufs-exynos.txt
diff --git a/Documentation/devicetree/bindings/ufs/ufs-exynos.txt
b/Documentation/devicetree/bindings/ufs/ufs-exynos.txt
new file mode 100644
index ..042dedf4e323
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/ufs-exynos.txt
@@ -0,0 +1,104 @@
+* Exynos Universal Flash Storage (UFS) Host Controller
+
+UFSHC nodes are defined to describe on-chip UFS host controllers.
+Each UFS controller instance should have its own node.
+
+Required properties:
+- compatible: compatible name, contains "samsung,exynos7-ufs"
+- interrupts:
+- reg : Should contain HCI, vendor specific, UNIPRO and
+ UFS protector address space
+- reg-names: "hci", "vs_hci", "unipro", "ufsp";
+
+Optional properties:
+- vdd-hba-supply: phandle to UFS host controller supply regulator node
+- vcc-supply: phandle to VCC supply regulator node
+- vccq-supply : phandle to VCCQ supply regulator node
+- vccq2-supply : phandle to VCCQ2 supply regulator node
+- vcc-supply-1p8: For embedded UFS devices, valid VCC range is
1.7-1.95V
+ or 2.7-3.6V. This boolean property when set,
specifies
+ to use low voltage range of 1.7-1.95V. Note for
external
+ UFS cards this property is invalid and valid VCC
range is
+ always 2.7-3.6V.
+- vcc-max-microamp : specifies max. load that can be drawn from vcc supply
+- vccq-max-microamp : specifies max. load that can be drawn from vccq
supply
+- vccq2-max-microamp: specifies max. load that can be drawn from vccq2
supply
+- -fixed-regulator : boolean property specifying that -supply is a
fixed regulator
+
+- clocks: List of phandle and clock specifier pairs
+- clock-names : List of clock input name strings sorted in the same
+ order as the clocks property.
+ "core", "sclk_unipro_main", "ref" and ref_parent
+
+- freq-table-hz: Array of operating frequencies
stored in the same
+ order as the clocks property. If this property is not
+ defined or a value in the array is "0" then it is
assumed
+ that the frequency is set by the parent clock or a
+ fixed rate clock source.
+- pclk-freq-avail-range : specifies available frequency range(min/max) for APB
clock
+- ufs,pwr-attr-mode : specifies mode value for power mode change, possible
values are
+ "FAST", "SLOW", "FAST_auto" and "SLOW_auto"
+- ufs,pwr-attr-lane : specifies lane count value for power mode change
+ allowed values are 1 or 2
+- ufs,pwr-attr-gear : specifies gear count value for power mode change
+ allowed values are 1 or 2
+- ufs,pwr-attr-hs-series : specifies HS rate series for power mode change
+ can be one of "HS_rate_b" or "HS_rate_a"
+- ufs,pwr-local-l2-timer : specifies array of local UNIPRO L2 timer values
+ 3 timers supported
+
+- ufs,pwr-remote-l2-timer : specifies array of remote UNIPRO L2 timer values
+ 3 timers supported
+
+- ufs-rx-adv-fine-gran-sup_en : specifies support of fine granularity of MPHY,
+ this is a boolean property.
+- ufs-rx-adv-fine-gran-step : specifies granularity steps of MPHY,
+ allowed step size is 0 to 3
+- ufs-rx-adv-min-activate-time-cap : specifies rx advanced minimum activate
time of MPHY
+range is 1 to 9
+- ufs-pa-granularity : specifies Granularity for PA_TActivate and
PA_Hibern8Time
+- ufs-pa-tacctivate : specifies time to wake-up remote M-RX
+- ufs-pa-hibern8time : specifies minimum time to wait in HIBERN8 state
+
+Note: If above properties are not defined it can be assumed that the supply
+regulators or clocks are always on.
+
+Example:
+ ufshc@0x1557 {
+ compatible = "samsung,exynos7-ufs";
+ reg = <0x1557 0x100>,
+ <0x15570100 0x100>,
+ <0x15571000 0x200>,
+ <0x15572000 0x300>;
+ reg-names = "hci", "vs_hci", "unipro", "ufsp";
+
[PATCH v4 11/11] scsi: ufs-exynos: add UFS host support for Exynos SoCs
From: Seungwon Jeon
This patch introduces Exynos UFS host controller driver,
which mainly handles vendor-specific operations including
link startup, power mode change and hibernation/unhibernation.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/Kconfig | 12 +
drivers/scsi/ufs/Makefile|1 +
drivers/scsi/ufs/ufs-exynos-hw.c | 131
drivers/scsi/ufs/ufs-exynos-hw.h | 43 ++
drivers/scsi/ufs/ufs-exynos.c| 1317 ++
drivers/scsi/ufs/ufs-exynos.h| 247 +++
drivers/scsi/ufs/ufshci.h| 26 +-
drivers/scsi/ufs/unipro.h| 47 ++
8 files changed, 1823 insertions(+), 1 deletion(-)
create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.c
create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.h
create mode 100644 drivers/scsi/ufs/ufs-exynos.c
create mode 100644 drivers/scsi/ufs/ufs-exynos.h
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 5f4530744e0a..bc602be94458 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -83,3 +83,15 @@ config SCSI_UFS_QCOM
Select this if you have UFS controller on QCOM chipset.
If unsure, say N.
+
+config SCSI_UFS_EXYNOS
+ bool "EXYNOS specific hooks to UFS controller platform driver"
+ depends on SCSI_UFSHCD_PLATFORM && ARCH_EXYNOS || COMPILE_TEST
+ select PHY_EXYNOS_UFS
+ help
+ This selects the EXYNOS specific additions to UFSHCD platform driver.
+ UFS host on EXYNOS includes HCI and UNIPRO layer, and associates with
+ UFS-PHY driver.
+
+ Select this if you have UFS host controller on EXYNOS chipset.
+ If unsure, say N.
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index 8303bcce7a23..2accf1e628b3 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -1,5 +1,6 @@
# UFSHCD makefile
obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o
+obj-$(CONFIG_SCSI_UFS_EXYNOS) += ufs-exynos.o ufs-exynos-hw.o
obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
diff --git a/drivers/scsi/ufs/ufs-exynos-hw.c b/drivers/scsi/ufs/ufs-exynos-hw.c
new file mode 100644
index ..be6c61541a8f
--- /dev/null
+++ b/drivers/scsi/ufs/ufs-exynos-hw.c
@@ -0,0 +1,131 @@
+/*
+ * UFS Host Controller driver for Exynos specific extensions
+ *
+ * Copyright (C) 2014-2015 Samsung Electronics Co., Ltd.
+ * Author: Seungwon Jeon
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include "ufshcd.h"
+#include "unipro.h"
+
+#include "ufs-exynos.h"
+#include "ufs-exynos-hw.h"
+
+static int exynos7_ufs_drv_init(struct device *dev, struct exynos_ufs *ufs)
+{
+ struct clk *child, *parent;
+
+ child = devm_clk_get(dev, "ref_clk");
+ if (IS_ERR(child)) {
+ dev_err(dev, "failed to get ref_clk clock\n");
+ return -EINVAL;
+ }
+
+ parent = devm_clk_get(dev, "ref_clk_parent");
+ if (IS_ERR(parent)) {
+ dev_err(dev, "failed to get ref_clk_parent clock\n");
+ return -EINVAL;
+ }
+ return clk_set_parent(child, parent);
+}
+
+static int exynos7_ufs_pre_link(struct exynos_ufs *ufs)
+{
+ struct ufs_hba *hba = ufs->hba;
+ u32 val = ufs->drv_data->uic_attr->pa_dbg_option_suite;
+ int i;
+
+ exynos_ufs_enable_ov_tm(hba);
+ for_each_ufs_tx_lane(ufs, i)
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x297, i), 0x17);
+ for_each_ufs_rx_lane(ufs, i) {
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x362, i), 0xff);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x363, i), 0x00);
+ }
+ exynos_ufs_disable_ov_tm(hba);
+
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_OPTION_SUITE_DYN), 0xf);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_OPTION_SUITE_DYN), 0xf);
+ for_each_ufs_tx_lane(ufs, i)
+ ufshcd_dme_set(hba,
+ UIC_ARG_MIB_SEL(TX_HIBERN8_CONTROL, i), 0x0);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_TXPHY_CFGUPDT), 0x1);
+ udelay(1);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_OPTION_SUITE), val | (1 << 12));
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_SKIP_RESET_PHY), 0x1);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_SKIP_LINE_RESET), 0x1);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_LINE_RESET_REQ), 0x1);
+ udelay(1600);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_OPTION_SUITE), val);
+
+ return 0;
+}
+
+static int exynos7_ufs_post_link(struct exynos_ufs *ufs)
+{
+ struct
Re: [PATCH v4 02/11] phy: exynos-ufs: add UFS PHY driver for EXYNOS SoC
Hi,
On Wed, Oct 14, 2015 at 9:31 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Wednesday 14 October 2015 06:25 PM, Alim Akhtar wrote:
>> From: Seungwon Jeon
>>
>> This patch introduces Exynos UFS PHY driver. This driver
>> supports to deal with phy calibration and power control
>> according to UFS host driver's behavior.
>>
>> Signed-off-by: Seungwon Jeon
>> Signed-off-by: Alim Akhtar
>> Cc: Kishon Vijay Abraham I
>> ---
>> drivers/phy/Kconfig|7 +
>> drivers/phy/Makefile |1 +
>> drivers/phy/phy-exynos-ufs.c | 257
>>
>> drivers/phy/phy-exynos-ufs.h | 88
>> drivers/phy/phy-exynos7-ufs.h | 89 +
>> include/linux/phy/phy-exynos-ufs.h | 101 ++
>> 6 files changed, 543 insertions(+)
>> create mode 100644 drivers/phy/phy-exynos-ufs.c
>> create mode 100644 drivers/phy/phy-exynos-ufs.h
>> create mode 100644 drivers/phy/phy-exynos7-ufs.h
>> create mode 100644 include/linux/phy/phy-exynos-ufs.h
>>
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 47da573d0bab..499eec4a967c 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -371,4 +371,11 @@ config PHY_BRCMSTB_SATA
>> Enable this to support the SATA3 PHY on 28nm Broadcom STB SoCs.
>> Likely useful only with CONFIG_SATA_BRCMSTB enabled.
>>
>> +config PHY_EXYNOS_UFS
>> + tristate "EXYNOS SoC series UFS PHY driver"
>> + depends on OF && ARCH_EXYNOS || COMPILE_TEST
>> + select GENERIC_PHY
>> + help
>> + Support for UFS PHY on Samsung EXYNOS chipsets.
>> +
>> endmenu
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index a5b18c18fc12..2a312ca20795 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -46,3 +46,4 @@ obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
>> obj-$(CONFIG_PHY_TUSB1210) += phy-tusb1210.o
>> obj-$(CONFIG_PHY_BRCMSTB_SATA) += phy-brcmstb-sata.o
>> obj-$(CONFIG_PHY_PISTACHIO_USB) += phy-pistachio-usb.o
>> +obj-$(CONFIG_PHY_EXYNOS_UFS) += phy-exynos-ufs.o
>> diff --git a/drivers/phy/phy-exynos-ufs.c b/drivers/phy/phy-exynos-ufs.c
>> new file mode 100644
>> index ..77330b85e3f8
>> --- /dev/null
>> +++ b/drivers/phy/phy-exynos-ufs.c
>> @@ -0,0 +1,257 @@
>> +/*
>> + * UFS PHY driver for Samsung EXYNOS SoC
>> + *
>> + * Copyright (C) 2015 Samsung Electronics Co., Ltd.
>> + * Author: Seungwon Jeon
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "phy-exynos-ufs.h"
>> +
>> +#define for_each_phy_lane(phy, i) \
>> + for (i = 0; i < (phy)->lane_cnt; i++)
>> +#define for_each_phy_cfg(cfg) \
>> + for (; (cfg)->id; (cfg)++)
>> +
>> +#define PHY_DEF_LANE_CNT 1
>> +
>> +static void exynos_ufs_phy_config(struct exynos_ufs_phy *phy,
>> + const struct exynos_ufs_phy_cfg *cfg, u8 lane)
>> +{
>> + enum {LANE_0, LANE_1}; /* lane index */
>> +
>> + switch (lane) {
>> + case LANE_0:
>> + writel(cfg->val, (phy)->reg_pma + cfg->off_0);
>> + break;
>> + case LANE_1:
>> + if (cfg->id == PHY_TRSV_BLK)
>> + writel(cfg->val, (phy)->reg_pma + cfg->off_1);
>> + break;
>> + }
>> +}
>> +
>> +static bool match_cfg_to_pwr_mode(u8 desc, u8 required_pwr)
>> +{
>> + if (IS_PWR_MODE_ANY(desc))
>> + return true;
>> +
>> + if (IS_PWR_MODE_HS(required_pwr) && IS_PWR_MODE_HS_ANY(desc))
>> + return true;
>> +
>> + if (COMP_PWR_MODE(required_pwr, desc))
>> + return true;
>> +
>> + if (COMP_PWR_MODE_MD(required_pwr, desc) &&
>> + COMP_PWR_MODE_GEAR(required_pwr, desc) &&
>> + COMP_PWR_MODE
Re: [PATCH v4 11/11] scsi: ufs-exynos: add UFS host support for Exynos SoCs
+CCing kishon Vijay,
On 10/14/2015 06:25 PM, Alim Akhtar wrote:
From: Seungwon Jeon
This patch introduces Exynos UFS host controller driver,
which mainly handles vendor-specific operations including
link startup, power mode change and hibernation/unhibernation.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/Kconfig | 12 +
drivers/scsi/ufs/Makefile|1 +
drivers/scsi/ufs/ufs-exynos-hw.c | 131
drivers/scsi/ufs/ufs-exynos-hw.h | 43 ++
drivers/scsi/ufs/ufs-exynos.c| 1317 ++
drivers/scsi/ufs/ufs-exynos.h| 247 +++
drivers/scsi/ufs/ufshci.h| 26 +-
drivers/scsi/ufs/unipro.h| 47 ++
8 files changed, 1823 insertions(+), 1 deletion(-)
create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.c
create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.h
create mode 100644 drivers/scsi/ufs/ufs-exynos.c
create mode 100644 drivers/scsi/ufs/ufs-exynos.h
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 5f4530744e0a..bc602be94458 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -83,3 +83,15 @@ config SCSI_UFS_QCOM
Select this if you have UFS controller on QCOM chipset.
If unsure, say N.
+
+config SCSI_UFS_EXYNOS
+ bool "EXYNOS specific hooks to UFS controller platform driver"
+ depends on SCSI_UFSHCD_PLATFORM && ARCH_EXYNOS || COMPILE_TEST
+ select PHY_EXYNOS_UFS
+ help
+ This selects the EXYNOS specific additions to UFSHCD platform driver.
+ UFS host on EXYNOS includes HCI and UNIPRO layer, and associates with
+ UFS-PHY driver.
+
+ Select this if you have UFS host controller on EXYNOS chipset.
+ If unsure, say N.
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index 8303bcce7a23..2accf1e628b3 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -1,5 +1,6 @@
# UFSHCD makefile
obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o
+obj-$(CONFIG_SCSI_UFS_EXYNOS) += ufs-exynos.o ufs-exynos-hw.o
obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
diff --git a/drivers/scsi/ufs/ufs-exynos-hw.c b/drivers/scsi/ufs/ufs-exynos-hw.c
new file mode 100644
index ..be6c61541a8f
--- /dev/null
+++ b/drivers/scsi/ufs/ufs-exynos-hw.c
@@ -0,0 +1,131 @@
+/*
+ * UFS Host Controller driver for Exynos specific extensions
+ *
+ * Copyright (C) 2014-2015 Samsung Electronics Co., Ltd.
+ * Author: Seungwon Jeon
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include "ufshcd.h"
+#include "unipro.h"
+
+#include "ufs-exynos.h"
+#include "ufs-exynos-hw.h"
+
+static int exynos7_ufs_drv_init(struct device *dev, struct exynos_ufs *ufs)
+{
+ struct clk *child, *parent;
+
+ child = devm_clk_get(dev, "ref_clk");
+ if (IS_ERR(child)) {
+ dev_err(dev, "failed to get ref_clk clock\n");
+ return -EINVAL;
+ }
+
+ parent = devm_clk_get(dev, "ref_clk_parent");
+ if (IS_ERR(parent)) {
+ dev_err(dev, "failed to get ref_clk_parent clock\n");
+ return -EINVAL;
+ }
+ return clk_set_parent(child, parent);
+}
+
+static int exynos7_ufs_pre_link(struct exynos_ufs *ufs)
+{
+ struct ufs_hba *hba = ufs->hba;
+ u32 val = ufs->drv_data->uic_attr->pa_dbg_option_suite;
+ int i;
+
+ exynos_ufs_enable_ov_tm(hba);
+ for_each_ufs_tx_lane(ufs, i)
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x297, i), 0x17);
+ for_each_ufs_rx_lane(ufs, i) {
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x362, i), 0xff);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x363, i), 0x00);
+ }
+ exynos_ufs_disable_ov_tm(hba);
+
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_OPTION_SUITE_DYN), 0xf);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_OPTION_SUITE_DYN), 0xf);
+ for_each_ufs_tx_lane(ufs, i)
+ ufshcd_dme_set(hba,
+ UIC_ARG_MIB_SEL(TX_HIBERN8_CONTROL, i), 0x0);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_TXPHY_CFGUPDT), 0x1);
+ udelay(1);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_OPTION_SUITE), val | (1 << 12));
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_SKIP_RESET_PHY), 0x1);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_SKIP_LINE_RESET), 0x1);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_LINE_RESET_REQ), 0x1);
+ udelay(1600);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_OPTION_SUITE), val);
+
+ return 0;
+}
Re: [PATCH v2 0/6] ARM: dts: Use correct CD properties for SDIO and eMMC in Snow and Peach
Hi Javier,
On 10/15/2015 10:21 PM, Javier Martinez Canillas wrote:
Hello,
The Exynos Chromebooks DTS don't use the correct card detection properties
since these were carried from the vendor tree that had a reason to do so.
There are two things that I noticed:
1) The Marvell WiFi SDIO is marked as broken-cd instead of non-removable:
This causes the device to be removed when the system enters into a suspend
state which leads to the following warning when the system is resumed:
[ 181.944636] mmc2: error -2 during resume (card was removed?)
The rationale for using broken-cd is explained in downstream commit [0] and
was that using the non-removable property caused issues with the mwifiex
driver since the reset logic called the mmc_{remove,add}_host() functions.
But the reset logic in the mwifiex mainline driver has changed and this is
no longer the case so it's safe to use the non-removable property AFAICT.
Good to know it is fixed now. This is fixed in firmware or in the driver?
2) The eMMC node has both broken-cd and non-removable but the MMC DT binding
doc (Documentation/devicetree/bindings/mmc/mmc.txt) mentions that only one
of these card detection properties should be used.
This change looks ok, will take a closer look once I am back to my work
station.
So this series change both the SDIO WiFi and eMMC device nodes in the Snow,
Peach Pi and Peach Pit boards DTS to use the non-removable property.
To test, I've cherry picked commit [1] from the vendor tree that adds a
debugfs entry to force a card reset and after the reset, the WiFi card still
works correctly:
$ echo 1 > /sys/kernel/debug/mwifiex/mlan0/reset
And also tested that both eMMC and WiFi are working correctly after a S2R.
The test were made on an Exynos5800 Peach Pi but I don't have access to a
Snow anymore so testing patch 3/6 and 6/6 on that board will be appreciated.
v1 of the series was [2] and this version fixes issues pointed out by Tomeu.
Changes since v1:
- Replace broken-cd for non-removable in the correct mmc node for Snow.
- Correct the card detetion properties for eMMC in Snow, Pit and Pi.
- Also remove the card-detect-delay property when using non-removable.
[0]:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ad348e1e2381
[1]:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5995363523de
[2]: https://lkml.org/lkml/2015/10/15/294
Best regards,
Javier
Javier Martinez Canillas (6):
ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi
ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit
ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common
ARM: dts: Remove broken-cd from eMMC node in exynos5800-peach-pi
ARM: dts: Remove broken-cd from eMMC node in exynos5420-peach-pi
ARM: dts: Mark eMMC as non-removable in exynos5250-snow-common
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 6 ++
arch/arm/boot/dts/exynos5420-peach-pit.dts| 5 +
arch/arm/boot/dts/exynos5800-peach-pi.dts | 5 +
3 files changed, 4 insertions(+), 12 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler
CCing Doug, Heiko and Enric Balletbo To help us by testing on rk3288-veyron and am335x-sl50 boards. On 10/22/2015 08:22 AM, Javier Martinez Canillas wrote: Hello Krzysztof, On 10/22/2015 03:43 AM, Krzysztof Kozlowski wrote: On 22.10.2015 10:20, Javier Martinez Canillas wrote:> Hello Krzysztof, Thanks for your feedback. On 10/22/2015 02:36 AM, Krzysztof Kozlowski wrote: On 22.10.2015 00:15, Javier Martinez Canillas wrote: The pwrseq_emmc driver does a eMMC card reset before a system reboot to allow broken or limited ROM boot-loaders (that don't have an eMMC reset logic) to be able to read the second stage from the eMMC. But this has to be called before a system reboot handler and while most of them use the priority 128, there are other restart handlers (such as the syscon-reboot one) that use a higher priority. So, use the highest priority to make sure that the eMMC hw is reset before a system reboot. Signed-off-by: Javier Martinez Canillas Tested-by: Markus Reichl Tested-by: Anand Moon Reviewed-by: Alim Akhtar --- Hello, This patch was needed since a recent series from Alim [0] added syscon reboot and poweroff support to Exynos SoCs and removed the reset handler in the Exynos Power Management Unit (PMU) code. But the PMU and syscon-reboot restart handler have a different priority so [0] breaks restart when eMMC is used on these boards. [0]: http://www.spinics.net/lists/arm-kernel/msg454396.html So this patch must be merged before [0] to avoid regressions. Best regards, Javier drivers/mmc/core/pwrseq_emmc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/core/pwrseq_emmc.c b/drivers/mmc/core/pwrseq_emmc.c index 137c97fb7aa8..ad4f94ec7e8d 100644 --- a/drivers/mmc/core/pwrseq_emmc.c +++ b/drivers/mmc/core/pwrseq_emmc.c @@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct mmc_host *host, /* * register reset handler to ensure emmc reset also from -* emergency_reboot(), priority 129 schedules it just before -* system reboot +* emergency_reboot(), priority 255 is the highest priority +* so it will be executed before any system reboot handler. */ pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb; - pwrseq->reset_nb.priority = 129; + pwrseq->reset_nb.priority = 255; I see the problem which you are trying to solve but this may be tricker then just kicking the number. Some of restart handlers are registered with priority 192. I found few of such, like: at91_restart_nb, zynq_slcr_restart_nb, rmobile_reset_nb (maybe more, I did not grep too much). Yes, the syscon-reboot restart handler also uses a priority 192 and that is why reboot with eMMC broke with Alim's patches since the PMU restart handler priority is 128. I guess they chose the "192" priority on purpose. I tried to understand what's the policy w.r.t priority numbering for restart handlers but only found this in the register_restart_handler kernel-doc [0]: /** * register_restart_handler - Register function to be called to reset *the system * @nb: Info about handler function to be called * @nb->priority: Handler priority. Handlers should follow the * following guidelines for setting priorities. * 0: Restart handler of last resort, * with limited restart capabilities * 128:Default restart handler; use if no other * restart handler is expected to be available, * and/or if restart functionality is * sufficient to restart the entire system * 255:Highest priority restart handler, will * preempt all other restart handlers So, reading that is not clear to me if only the values 0, 128 and 255 should be used or any value from 0-255. What's clear to me is that restart handlers to reset a specific hw block should be called before the restart handler that resets the whole system. The 192 seems to be used because there are other default restart handlers that are using a prio of 128. See for example the commit that changed the syscon-reboot prio from 128 to 192: b81180b3fd48 power: reset: adjust priority of simple syscon reboot driver But were are here not talking about syscon handler but the others. Now you will be ahead of them. Yes, I know that. My point was that the platforms were either not using the mmc-pwrseq-emmc or their system restart handler already had a lower priority but that is not true for at least rk3288-veyron as you said. So probably the 192 value was chosen because is in the middle of 128 and 255 but it seems to me a rather arbitrary value and I would prefer it to be documented in some place. Effectively, now the emmc h
Re: [PATCH v4 00/11] exynos-ufs: add support for Exynos
A Gentle Reminder !! On 10/14/2015 06:25 PM, Alim Akhtar wrote: This patch-set introduces UFS (Universal Flash Storage) host support for Samsung Exynos SoC. Mostly, it consists of UFS PHY and host specific driver. And it also contains some quirks handling for Exynos. NOTE: ** This series has a dependency on [4]. ** -Changes since v3: * Fixed compilation warrings as reported by "Kbuild Test Robot"[5]. * Restructure the driver to make it as a platform driver, rebased on top of [4]. * Addressed review comments from Arnd Bergmann[5]. * Other misc changes and improvements. -Changes since v2: * Addressed review comments from Kishon[1] and Rob Herring [2] * Splited ufs dt binding documetation from ufs driver patch -Changes since v1: * Addressed review comments from Alexey[3] and various review comments from Amit. * Updated email id of Seungwon as his samsung id is void now. * Added ufs platform data [1]-> https://lkml.org/lkml/2015/9/18/29 [2]-> https://lkml.org/lkml/2015/9/21/668 [3]-> https://lkml.org/lkml/2015/8/23/124 [4]-> https://lkml.org/lkml/2015/9/2/364 [5]-> https://lkml.org/lkml/2015/10/1/402 This patch set is tested on exynos7-espresso board. Alim Akhtar (1): Documentation: samsung-phy: Add dt bindings for UFS Seungwon Jeon (10): phy: exynos-ufs: add UFS PHY driver for EXYNOS SoC scsi: ufs: add quirk to contain unconformable utrd field scsi: ufs: add quirk to fix mishandling utrlclr/utmrlclr scsi: ufs: add quirk not to allow reset of interrupt aggregation scsi: ufs: add quirk to enable host controller without hce scsi: ufs: add specific callback for nexus type scsi: ufs: add add specific callback for hibern8 scsi: ufs: make ufshcd_config_pwr_mode of non-static func Documentation: devicetree: ufs: Add DT bindings for exynos UFS host controller scsi: ufs-exynos: add UFS host support for Exynos SoCs .../devicetree/bindings/phy/samsung-phy.txt| 22 + .../devicetree/bindings/ufs/ufs-exynos.txt | 104 ++ drivers/phy/Kconfig|7 + drivers/phy/Makefile |1 + drivers/phy/phy-exynos-ufs.c | 257 drivers/phy/phy-exynos-ufs.h | 88 ++ drivers/phy/phy-exynos7-ufs.h | 89 ++ drivers/scsi/ufs/Kconfig | 12 + drivers/scsi/ufs/Makefile |1 + drivers/scsi/ufs/ufs-exynos-hw.c | 131 ++ drivers/scsi/ufs/ufs-exynos-hw.h | 43 + drivers/scsi/ufs/ufs-exynos.c | 1317 drivers/scsi/ufs/ufs-exynos.h | 247 drivers/scsi/ufs/ufshcd.c | 168 ++- drivers/scsi/ufs/ufshcd.h | 54 + drivers/scsi/ufs/ufshci.h | 26 +- drivers/scsi/ufs/unipro.h | 47 + include/linux/phy/phy-exynos-ufs.h | 101 ++ 18 files changed, 2695 insertions(+), 20 deletions(-) create mode 100644 Documentation/devicetree/bindings/ufs/ufs-exynos.txt create mode 100644 drivers/phy/phy-exynos-ufs.c create mode 100644 drivers/phy/phy-exynos-ufs.h create mode 100644 drivers/phy/phy-exynos7-ufs.h create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.c create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.h create mode 100644 drivers/scsi/ufs/ufs-exynos.c create mode 100644 drivers/scsi/ufs/ufs-exynos.h create mode 100644 include/linux/phy/phy-exynos-ufs.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/6] ARM: dts: Use correct CD properties for SDIO and eMMC in Snow and Peach
Hi Javier,
On 10/15/2015 10:21 PM, Javier Martinez Canillas wrote:
Hello,
The Exynos Chromebooks DTS don't use the correct card detection properties
since these were carried from the vendor tree that had a reason to do so.
There are two things that I noticed:
1) The Marvell WiFi SDIO is marked as broken-cd instead of non-removable:
This causes the device to be removed when the system enters into a suspend
state which leads to the following warning when the system is resumed:
[ 181.944636] mmc2: error -2 during resume (card was removed?)
The rationale for using broken-cd is explained in downstream commit [0] and
was that using the non-removable property caused issues with the mwifiex
driver since the reset logic called the mmc_{remove,add}_host() functions.
But the reset logic in the mwifiex mainline driver has changed and this is
no longer the case so it's safe to use the non-removable property AFAICT.
2) The eMMC node has both broken-cd and non-removable but the MMC DT binding
doc (Documentation/devicetree/bindings/mmc/mmc.txt) mentions that only one
of these card detection properties should be used.
So this series change both the SDIO WiFi and eMMC device nodes in the Snow,
Peach Pi and Peach Pit boards DTS to use the non-removable property.
To test, I've cherry picked commit [1] from the vendor tree that adds a
debugfs entry to force a card reset and after the reset, the WiFi card still
works correctly:
$ echo 1 > /sys/kernel/debug/mwifiex/mlan0/reset
And also tested that both eMMC and WiFi are working correctly after a S2R.
The test were made on an Exynos5800 Peach Pi but I don't have access to a
Snow anymore so testing patch 3/6 and 6/6 on that board will be appreciated.
v1 of the series was [2] and this version fixes issues pointed out by Tomeu.
Changes since v1:
- Replace broken-cd for non-removable in the correct mmc node for Snow.
- Correct the card detetion properties for eMMC in Snow, Pit and Pi.
- Also remove the card-detect-delay property when using non-removable.
[0]:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ad348e1e2381
[1]:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5995363523de
[2]: https://lkml.org/lkml/2015/10/15/294
Best regards,
Javier
Javier Martinez Canillas (6):
ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi
ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit
ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common
ARM: dts: Remove broken-cd from eMMC node in exynos5800-peach-pi
ARM: dts: Remove broken-cd from eMMC node in exynos5420-peach-pi
ARM: dts: Mark eMMC as non-removable in exynos5250-snow-common
This series looks good to me, so feel free to add
Reviewed-by: Alim Akhtar
and for patch 4 and 5: Tested-by: Alim Akhtar
Thanks.
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 6 ++
arch/arm/boot/dts/exynos5420-peach-pit.dts| 5 +
arch/arm/boot/dts/exynos5800-peach-pi.dts | 5 +
3 files changed, 4 insertions(+), 12 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler
On 10/22/2015 09:04 PM, Doug Anderson wrote:
Krzysztof,
On Wed, Oct 21, 2015 at 6:43 PM, Krzysztof Kozlowski
wrote:
I think at least one platform may be affected because it used
mmc-pwrseq-emmc and gpio-restart.
Look at rk3288-veyron.dtsi.
Both of restart handlers had the priority of 129 which means that the
order of execution depends on probing sequence. Now you will make the
sequence strict - first mmc then gpio.
You seems convinced that this is not a problem... I don't know. I would
prefer test this on affected platforms before risking to break them.
It's annoying if fix for one SoC breaks another.
Assuming I'm understanding things properly, veyron isn't using 129 as
a priority. In the dts file:
gpio-restart {
compatible = "gpio-restart";
gpios = <&gpio0 13 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&ap_warm_reset_h>;
priority = <200>;
};
...so it overrides the default 129 with 200. Ah, but Javier already
pointed that out in his reply.
Since the current mmc_pwrseq_emmc_reset_nb notifier priority is 129,
eMMC reset will not work if one of the platforms you mentioned needs
this since the system restart handler with prio 192 will be executed
before the eMMC one, leaving the eMMC in an unknown state on reboot.
And now you will "fix this" by making eMMC working correctly. So let's
make it straight:
1. Previously the eMMC could be left on these platforms in an unknown
state (because emmc handler was not executed).
2. No one complained! Which could mean that in fact this was working fine...
3. Now you will change it.
4. Maybe someone will complain?
On veyron boards the reset shouldn't hurt. The eMMC reset will
actually get asserted at reset anyway since the reset will reset GPIO
states and the default GPIO state for the eMMC line asserts reset.
OK, I just picked this onto Heiko's somewhat "stable-tree"
(v4.3-rc3-876-g6509232) from
Re: [PATCH v4 11/11] scsi: ufs-exynos: add UFS host support for Exynos SoCs
Hi Kishon
Thanks again for you review.
On Fri, Oct 23, 2015 at 8:48 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Thursday 15 October 2015 08:38 AM, Alim Akhtar wrote:
>> +CCing kishon Vijay,
>>
>> On 10/14/2015 06:25 PM, Alim Akhtar wrote:
>>> From: Seungwon Jeon
>>>
>>> This patch introduces Exynos UFS host controller driver,
>>> which mainly handles vendor-specific operations including
>>> link startup, power mode change and hibernation/unhibernation.
>>>
>>> Signed-off-by: Seungwon Jeon
>>> Signed-off-by: Alim Akhtar
>>> ---
>>> drivers/scsi/ufs/Kconfig | 12 +
>>> drivers/scsi/ufs/Makefile|1 +
>>> drivers/scsi/ufs/ufs-exynos-hw.c | 131
>>> drivers/scsi/ufs/ufs-exynos-hw.h | 43 ++
>>> drivers/scsi/ufs/ufs-exynos.c| 1317
>>> ++
>>> drivers/scsi/ufs/ufs-exynos.h| 247 +++
>>> drivers/scsi/ufs/ufshci.h| 26 +-
>>> drivers/scsi/ufs/unipro.h| 47 ++
>>> 8 files changed, 1823 insertions(+), 1 deletion(-)
>>> create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.c
>>> create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.h
>>> create mode 100644 drivers/scsi/ufs/ufs-exynos.c
>>> create mode 100644 drivers/scsi/ufs/ufs-exynos.h
>>>
> .
> .
>
> .
> .
>>> diff --git a/drivers/scsi/ufs/ufs-exynos-hw.c
>>> b/drivers/scsi/ufs/ufs-exynos-hw.c
>>> new file mode 100644
>>> index ..be6c61541a8f
>>> --- /dev/null
>>> +++ b/drivers/scsi/ufs/ufs-exynos-hw.c
>>> @@ -0,0 +1,131 @@
> .
> .
>
> .
> .
>>> +
>>> +#define PWR_MODE_STR_LEN64
>>> +static int exynos_ufs_post_pwr_mode(struct ufs_hba *hba,
>>> +struct ufs_pa_layer_attr *pwr_max,
>>> +struct ufs_pa_layer_attr *pwr_req)
>>> +{
>>> +struct exynos_ufs *ufs = to_exynos_ufs(hba);
>>> +struct exynos_ufs_phy_info *phy_info = phy_get_drvdata(ufs->phy);
>
> This is abusing the interface. phy_get_drvdata is meant to be used only
> by the PHY driver.
>>> +struct exynos_ufs_phy_specific_ops *phy_ops =
>>> +phy_info->phy_specific_ops;
>
> I'm really not happy about having platform specific ops for PHY. We have
> to see if existing PHY ops can be used for this or in worst case add new
> PHY ops.
Well you said you like the controller driver to use only PHY ops[1], I
am sorry If I misunderstood that point, can you please help me to
understand that?
[1]-> https://lkml.org/lkml/2015/9/18/29
>>> +struct uic_pwr_mode *pwr = &ufs->pwr_act;
>>> +char pwr_str[PWR_MODE_STR_LEN] = "";
>>> +int ret = 0;
>>> +
>>> +if (ufs->drv_data->post_pwr_change)
>>> +ufs->drv_data->post_pwr_change(ufs, pwr);
>>> +
>>> +if (IS_UFS_PWR_MODE_HS(pwr->mode)) {
>>> +switch (pwr->hs_series) {
>>> +case PA_HS_MODE_A:
>>> +case PA_HS_MODE_B:
>>> +phy_ops->calibrate_phy(ufs->phy, CFG_POST_PWR_HS,
>>> +PWR_MODE_HS(pwr->gear, pwr->hs_series));
>>> +break;
>>> +}
>>> +
>>> +ret = phy_ops->wait_for_lock_acq(ufs->phy);
>>> +snprintf(pwr_str, sizeof(pwr_str), "Fast%s series_%s G_%d L_%d",
>>> +pwr->mode == FASTAUTO_MODE ? "_Auto" : "",
>>> +pwr->hs_series == PA_HS_MODE_A ? "A" : "B",
>>> +pwr->gear, pwr->lane);
>>> +} else if (IS_UFS_PWR_MODE_PWM(pwr->mode)) {
>>> +snprintf(pwr_str, sizeof(pwr_str), "Slow%s G_%d L_%d",
>>> +pwr->mode == SLOWAUTO_MODE ? "_Auto" : "",
>>> +pwr->gear, pwr->lane);
>>> +}
>>> +
>>> +dev_info(hba->dev, "Power mode change %d : %s\n", ret, pwr_str);
>>> +return ret;
>>> +}
>>> +
>>> +static void exynos_ufs_specify_nexus_t_xfer_req(struct ufs_hba *hba,
>>> +int tag, struct scsi_cmnd *cmd)
>>> +{
>>> +struct exynos_ufs *ufs = to_exynos_ufs(hba);
>>> +u32 type;
>>> +
>>> +type = hci_readl(ufs, HCI_UTRL_NEXUS_TYPE);
>>> +
>>> +if (cmd)
>>> +hci_writel(ufs, type | (1 <
[PATCH v2 1/5] dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC
From: Thomas Abraham Add dt-binding documentation for s2mps15 PMIC device. The s2mps15 device is similar to s2mps11/14 PMIC device and has 27 LDO and 10 buck regulators. Cc: devicet...@vger.kernel.org Signed-off-by: Thomas Abraham Signed-off-by: Alim Akhtar Reviewed-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/mfd/s2mps11.txt | 23 ++--- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt index 890f0b0e1643..c0427c9d0886 100644 --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt @@ -1,5 +1,5 @@ -* Samsung S2MPS11, S2MPS13, S2MPS14 and S2MPU02 Voltage and Current Regulator +* Samsung S2MPS11/13/14/15 and S2MPU02 Voltage and Current Regulator The Samsung S2MPS11 is a multi-function device which includes voltage and current regulators, RTC, charger controller and other sub-blocks. It is @@ -7,8 +7,12 @@ interfaced to the host controller using an I2C interface. Each sub-block is addressed by the host system using different I2C slave addresses. Required properties: -- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps13-pmic" - or "samsung,s2mps14-pmic" or "samsung,s2mpu02-pmic". +- compatible: Should be one of the following + - "samsung,s2mps11-pmic" + - "samsung,s2mps13-pmic" + - "samsung,s2mps14-pmic" + - "samsung,s2mps15-pmic" + - "samsung,s2mpu02-pmic". - reg: Specifies the I2C slave address of the pmic block. It should be 0x66. Optional properties: @@ -24,7 +28,7 @@ Optional properties: unwanted buck warm reset (setting buck voltages to default values). Optional nodes: -- clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered 32.768 +- clocks: s2mps11, s2mps13, s2mps15 and s5m8767 provide three(AP/CP/BT) buffered 32.768 KHz outputs, so to register these as clocks with common clock framework instantiate a sub-node named "clocks". It uses the common clock binding documented in : @@ -37,12 +41,13 @@ Optional nodes: the clock which they consume. Clock ID Devices -- -32KhzAP0S2MPS11, S2MPS13, S2MPS14, S5M8767 -32KhzCP1S2MPS11, S2MPS13, S5M8767 -32KhzBT2S2MPS11, S2MPS13, S2MPS14, S5M8767 +32KhzAP0S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767 +32KhzCP1S2MPS11, S2MPS13, S2MPS15, S5M8767 +32KhzBT2S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767 - compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps13-clk", - "samsung,s2mps14-clk", "samsung,s5m8767-clk" + "samsung,s2mps14-clk", "samsung,s2mps15-clk", + "samsung,s5m8767-clk" - regulators: The regulators of s2mps11 that have to be instantiated should be included in a sub-node named 'regulators'. Regulator nodes included in this @@ -90,6 +95,7 @@ as per the datasheet of s2mps11. - S2MPS11: 1 to 38 - S2MPS13: 1 to 40 - S2MPS14: 1 to 25 + - S2MPS15: 1 to 27 - S2MPU02: 1 to 28 - Example: LDO1, LDO2, LDO28 - BUCKn @@ -97,6 +103,7 @@ as per the datasheet of s2mps11. - S2MPS11: 1 to 10 - S2MPS13: 1 to 10 - S2MPS14: 1 to 5 + - S2MPS15: 1 to 10 - S2MPU02: 1 to 7 - Example: BUCK1, BUCK2, BUCK9 -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/5] mfd: sec: add S2MPS15 PMIC support
Samsung's S2MPS15 PMIC is targetted to be used with Samsung's Exynos7 SoC. The S2MPS15 PMIC is similar in functionality to S2MPS11/14 PMIC. It contains 27 LDO and 10 Buck regulators, RTC, three 32.768 KHz clock outputs and allows programming these blocks via a I2C interface. This patch series adds initial support for LDO/Buck regulators of S2MPS15 PMIC. Changes since v1: * Added suggestion from Krzysztof [1]. * Added s2mps15's 32.768 clocks support. * Added s2mps15's rtc support. V1 of these patches (with a lesser features) were posted a year back, since then there is not much progress on this, this is my attempt to move things forward. [1]-> https://lkml.org/lkml/2014/10/14/67 This series is based on linux-next-20151022. This is tested on exynos7-espresso board. Alim Akhtar (2): clk: s2mps15: Add support for S2MPS15 clocks drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC Thomas Abraham (3): dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC mfd: sec: Add support for S2MPS15 PMIC regulator: s2mps11: add support for S2MPS15 regulators Documentation/devicetree/bindings/mfd/s2mps11.txt | 23 ++- drivers/clk/Kconfig |5 +- drivers/clk/clk-s2mps11.c | 24 +++ drivers/mfd/sec-core.c| 31 drivers/mfd/sec-irq.c |8 + drivers/regulator/Kconfig |4 +- drivers/regulator/s2mps11.c | 135 - drivers/rtc/rtc-s5m.c | 14 +- include/linux/mfd/samsung/core.h |1 + include/linux/mfd/samsung/s2mps15.h | 161 + 10 files changed, 392 insertions(+), 14 deletions(-) create mode 100644 include/linux/mfd/samsung/s2mps15.h -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/5] mfd: sec: Add support for S2MPS15 PMIC
From: Thomas Abraham
Add support for S2MPS15 PMIC which is similar to S2MPS11 PMIC. The S2MPS15
PMIC supports 27 LDO regulators, 10 buck regulators, RTC, three 32.768KHz
clock outputs and battery charger. This patch adds initial support for
LDO and buck regulators of S2MPS15 device.
Signed-off-by: Thomas Abraham
Signed-off-by: Alim Akhtar
[Alim: Added s2mps15_devs like rtc and clk and related changes]
Reviewed-by: Krzysztof Kozlowski
---
drivers/mfd/sec-core.c | 31 +++
drivers/mfd/sec-irq.c |8 ++
include/linux/mfd/samsung/core.h|1 +
include/linux/mfd/samsung/s2mps15.h | 161 +++
4 files changed, 201 insertions(+)
create mode 100644 include/linux/mfd/samsung/s2mps15.h
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 2626fc0b5b8c..db3d4d4ff805 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -96,6 +97,17 @@ static const struct mfd_cell s2mps14_devs[] = {
}
};
+static const struct mfd_cell s2mps15_devs[] = {
+ {
+ .name = "s2mps15-pmic",
+ }, {
+ .name = "s2mps15-rtc",
+ }, {
+ .name = "s2mps15-clk",
+ .of_compatible = "samsung,s2mps15-clk",
+ },
+};
+
static const struct mfd_cell s2mpa01_devs[] = {
{
.name = "s2mpa01-pmic",
@@ -125,6 +137,9 @@ static const struct of_device_id sec_dt_match[] = {
.compatible = "samsung,s2mps14-pmic",
.data = (void *)S2MPS14X,
}, {
+ .compatible = "samsung,s2mps15-pmic",
+ .data = (void *)S2MPS15X,
+ }, {
.compatible = "samsung,s2mpa01-pmic",
.data = (void *)S2MPA01,
}, {
@@ -226,6 +241,15 @@ static const struct regmap_config s2mps14_regmap_config = {
.cache_type = REGCACHE_FLAT,
};
+static const struct regmap_config s2mps15_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = S2MPS15_REG_LDODSCH4,
+ .volatile_reg = s2mps11_volatile,
+ .cache_type = REGCACHE_FLAT,
+};
+
static const struct regmap_config s2mpu02_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -387,6 +411,9 @@ static int sec_pmic_probe(struct i2c_client *i2c,
case S2MPS14X:
regmap = &s2mps14_regmap_config;
break;
+ case S2MPS15X:
+ regmap = &s2mps15_regmap_config;
+ break;
case S5M8763X:
regmap = &s5m8763_regmap_config;
break;
@@ -445,6 +472,10 @@ static int sec_pmic_probe(struct i2c_client *i2c,
sec_devs = s2mps14_devs;
num_sec_devs = ARRAY_SIZE(s2mps14_devs);
break;
+ case S2MPS15X:
+ sec_devs = s2mps15_devs;
+ num_sec_devs = ARRAY_SIZE(s2mps15_devs);
+ break;
case S2MPU02:
sec_devs = s2mpu02_devs;
num_sec_devs = ARRAY_SIZE(s2mpu02_devs);
diff --git a/drivers/mfd/sec-irq.c b/drivers/mfd/sec-irq.c
index 806fa8dbb22d..d77de431cc50 100644
--- a/drivers/mfd/sec-irq.c
+++ b/drivers/mfd/sec-irq.c
@@ -407,6 +407,11 @@ static const struct regmap_irq_chip s2mps14_irq_chip = {
S2MPS1X_IRQ_CHIP_COMMON_DATA,
};
+static const struct regmap_irq_chip s2mps15_irq_chip = {
+ .name = "s2mps15",
+ S2MPS1X_IRQ_CHIP_COMMON_DATA,
+};
+
static const struct regmap_irq_chip s2mpu02_irq_chip = {
.name = "s2mpu02",
.irqs = s2mpu02_irqs,
@@ -466,6 +471,9 @@ int sec_irq_init(struct sec_pmic_dev *sec_pmic)
case S2MPS14X:
sec_irq_chip = &s2mps14_irq_chip;
break;
+ case S2MPS15X:
+ sec_irq_chip = &s2mps15_irq_chip;
+ break;
case S2MPU02:
sec_irq_chip = &s2mpu02_irq_chip;
break;
diff --git a/include/linux/mfd/samsung/core.h b/include/linux/mfd/samsung/core.h
index a06098639399..6bc4bcd488ac 100644
--- a/include/linux/mfd/samsung/core.h
+++ b/include/linux/mfd/samsung/core.h
@@ -44,6 +44,7 @@ enum sec_device_type {
S2MPS11X,
S2MPS13X,
S2MPS14X,
+ S2MPS15X,
S2MPU02,
};
diff --git a/include/linux/mfd/samsung/s2mps15.h
b/include/linux/mfd/samsung/s2mps15.h
new file mode 100644
index ..7443af6a4bba
--- /dev/null
+++ b/include/linux/mfd/samsung/s2mps15.h
@@ -0,0 +1,161 @@
+/*
+ * s2mps15.h
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Fre
[PATCH v2 3/5] regulator: s2mps11: add support for S2MPS15 regulators
From: Thomas Abraham
The S2MPS15 PMIC is similar in functionality to S2MPS11/14 PMIC. It contains
27 LDO and 10 Buck regulators and allows programming these regulators via a
I2C interface. This patch adds initial support for LDO/Buck regulators of
S2MPS15 PMIC.
Signed-off-by: Thomas Abraham
Signed-off-by: Alim Akhtar
Reviewed-by: Krzysztof Kozlowski
---
drivers/regulator/Kconfig |4 +-
drivers/regulator/s2mps11.c | 135 ++-
2 files changed, 136 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 64bccff557be..3e3ee5b88b3f 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -588,10 +588,10 @@ config REGULATOR_S2MPA01
via I2C bus. S2MPA01 has 10 Bucks and 26 LDO outputs.
config REGULATOR_S2MPS11
- tristate "Samsung S2MPS11/S2MPS13/S2MPS14/S2MPU02 voltage regulator"
+ tristate "Samsung S2MPS11/13/14/15/S2MPU02 voltage regulator"
depends on MFD_SEC_CORE
help
-This driver supports a Samsung S2MPS11/S2MPS13/S2MPS14/S2MPU02 voltage
+This driver supports a Samsung S2MPS11/13/14/15/S2MPU02 voltage
output regulator via I2C bus. The chip is comprised of high efficient
Buck converters including Dual-Phase Buck converter, Buck-Boost
converter, various LDOs.
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index 72fc3c32db49..12c59158552c 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
/* The highest number of possible regulators for supported devices. */
@@ -661,6 +662,133 @@ static const struct regulator_desc s2mps14_regulators[] =
{
S2MPS14_BUCK1235_START_SEL),
};
+static struct regulator_ops s2mps15_reg_ldo_ops = {
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage= regulator_map_voltage_linear_range,
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = regulator_enable_regmap,
+ .disable= regulator_disable_regmap,
+ .get_voltage_sel= regulator_get_voltage_sel_regmap,
+ .set_voltage_sel= regulator_set_voltage_sel_regmap,
+};
+
+static struct regulator_ops s2mps15_reg_buck_ops = {
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage= regulator_map_voltage_linear_range,
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = regulator_enable_regmap,
+ .disable= regulator_disable_regmap,
+ .get_voltage_sel= regulator_get_voltage_sel_regmap,
+ .set_voltage_sel= regulator_set_voltage_sel_regmap,
+ .set_voltage_time_sel = regulator_set_voltage_time_sel,
+};
+
+#define regulator_desc_s2mps15_ldo(num, range) { \
+ .name = "LDO"#num,\
+ .id = S2MPS15_LDO##num, \
+ .ops= &s2mps15_reg_ldo_ops, \
+ .type = REGULATOR_VOLTAGE,\
+ .owner = THIS_MODULE, \
+ .linear_ranges = range,\
+ .n_linear_ranges = ARRAY_SIZE(range), \
+ .n_voltages = S2MPS15_LDO_N_VOLTAGES, \
+ .vsel_reg = S2MPS15_REG_L1CTRL + num - 1, \
+ .vsel_mask = S2MPS15_LDO_VSEL_MASK,\
+ .enable_reg = S2MPS15_REG_L1CTRL + num - 1, \
+ .enable_mask= S2MPS15_ENABLE_MASK \
+}
+
+#define regulator_desc_s2mps15_buck(num, range) { \
+ .name = "BUCK"#num, \
+ .id = S2MPS15_BUCK##num,\
+ .ops= &s2mps15_reg_buck_ops,\
+ .type = REGULATOR_VOLTAGE,\
+ .owner = THIS_MODULE, \
+ .linear_ranges = range,\
+ .n_linear_ranges = ARRAY_SIZE(range), \
+ .ramp_delay = 12500,\
+ .n_voltages = S2MPS15_BUCK_N_VOLTAGES, \
+ .vsel_reg = S2MPS15_REG_B1CTRL2 + ((num - 1) * 2),\
+ .vsel_mask = S2MPS15_BUCK_VSEL_MASK, \
+ .enable_reg = S2MPS15_REG_B1CTRL1 + ((num - 1) * 2),\
+ .enable_mask= S2MPS15_ENABLE_MASK \
+}
+
+/* voltage range for s2mps15 LDO 3, 5, 15, 16, 18, 20, 23 and 27 */
+static const struct regulator_linear_range s2mps15_ldo_voltage_ranges1[] = {
+ REGULATOR_LINEAR_RANGE(100, 0xc, 0
[PATCH v2 5/5] drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC
RTC found in s2mps15 is almost same as one found in s2mps14.
This patch add required changes to enable s2mps15 rtc timer.
Signed-off-by: Alim Akhtar
---
drivers/rtc/rtc-s5m.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index f2504b4eef34..ac3286a267ba 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -188,6 +188,7 @@ static inline int s5m_check_peding_alarm_interrupt(struct
s5m_rtc_info *info,
ret = regmap_read(info->regmap, S5M_RTC_STATUS, &val);
val &= S5M_ALARM0_STATUS;
break;
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
ret = regmap_read(info->s5m87xx->regmap_pmic, S2MPS14_REG_ST2,
@@ -253,6 +254,7 @@ static inline int s5m8767_rtc_set_alarm_reg(struct
s5m_rtc_info *info)
data &= ~S5M_RTC_TIME_EN_MASK;
break;
case S2MPS14X:
+ case S2MPS15X:
data |= S2MPS_RTC_RUDR_MASK;
break;
case S2MPS13X:
@@ -317,7 +319,8 @@ static int s5m_rtc_read_time(struct device *dev, struct
rtc_time *tm)
u8 data[info->regs->regs_count];
int ret;
- if (info->device_type == S2MPS14X || info->device_type == S2MPS13X) {
+ if (info->device_type == S2MPS14X || info->device_type == S2MPS15X ||
+ info->device_type == S2MPS13X) {
ret = regmap_update_bits(info->regmap,
info->regs->rtc_udr_update,
S2MPS_RTC_RUDR_MASK, S2MPS_RTC_RUDR_MASK);
@@ -339,6 +342,7 @@ static int s5m_rtc_read_time(struct device *dev, struct
rtc_time *tm)
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
s5m8767_data_to_tm(data, tm, info->rtc_24hr_mode);
@@ -366,6 +370,7 @@ static int s5m_rtc_set_time(struct device *dev, struct
rtc_time *tm)
s5m8763_tm_to_data(tm, data);
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
ret = s5m8767_tm_to_data(tm, data);
@@ -414,6 +419,7 @@ static int s5m_rtc_read_alarm(struct device *dev, struct
rtc_wkalrm *alrm)
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
s5m8767_data_to_tm(data, &alrm->time, info->rtc_24hr_mode);
@@ -463,6 +469,7 @@ static int s5m_rtc_stop_alarm(struct s5m_rtc_info *info)
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
for (i = 0; i < info->regs->regs_count; i++)
@@ -508,6 +515,7 @@ static int s5m_rtc_start_alarm(struct s5m_rtc_info *info)
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
data[RTC_SEC] |= ALARM_ENABLE_MASK;
@@ -548,6 +556,7 @@ static int s5m_rtc_set_alarm(struct device *dev, struct
rtc_wkalrm *alrm)
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
s5m8767_tm_to_data(&alrm->time, data);
@@ -631,6 +640,7 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info *info)
ret = regmap_raw_write(info->regmap, S5M_ALARM0_CONF, data, 2);
break;
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
data[0] = (0 << BCD_EN_SHIFT) | (1 << MODEL24_SHIFT);
@@ -679,6 +689,7 @@ static int s5m_rtc_probe(struct platform_device *pdev)
return -ENOMEM;
switch (platform_get_device_id(pdev)->driver_data) {
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
regmap_cfg = &s2mps14_rtc_regmap_config;
@@ -805,6 +816,7 @@ static const struct platform_device_id s5m_rtc_id[] = {
{ "s5m-rtc",S5M8767X },
{ "s2mps13-rtc",S2MPS13X },
{ "s2mps14-rtc",S2MPS14X },
+ { "s2mps15-rtc",S2MPS15X },
{ },
};
MODULE_DEVICE_TABLE(platform, s5m_rtc_id);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/5] clk: s2mps15: Add support for S2MPS15 clocks
S2MPS15 PMIC has three 32k buffered clocks outputs. This patch
adds supports for the same to the s2mps11 clock driver.
Signed-off-by: Alim Akhtar
---
drivers/clk/Kconfig |5 +++--
drivers/clk/clk-s2mps11.c | 24
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index a1fa61159179..037a314b5d76 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -120,9 +120,10 @@ config COMMON_CLK_S2MPS11
tristate "Clock driver for S2MPS1X/S5M8767 MFD"
depends on MFD_SEC_CORE
---help---
- This driver supports S2MPS11/S2MPS14/S5M8767 crystal oscillator
+ This driver supports S2MPS1X/S5M8767 crystal oscillator
clock. These multi-function devices have two (S2MPS14) or three
- (S2MPS11, S5M8767) fixed-rate oscillators, clocked at 32KHz each.
+ (S2MPS11/S2MPS13/S2MPS15/S5M8767) fixed-rate oscillators,
+ clocked at 32KHz each.
config CLK_TWL6040
tristate "External McPDM functional clock from twl6040"
diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
index d266299dfdb1..455500dca653 100644
--- a/drivers/clk/clk-s2mps11.c
+++ b/drivers/clk/clk-s2mps11.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -148,6 +149,24 @@ static struct clk_init_data
s2mps14_clks_init[S2MPS11_CLKS_NUM] = {
},
};
+static struct clk_init_data s2mps15_clks_init[S2MPS11_CLKS_NUM] = {
+ [S2MPS11_CLK_AP] = {
+ .name = "s2mps15_ap",
+ .ops = &s2mps11_clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+ [S2MPS11_CLK_CP] = {
+ .name = "s2mps15_cp",
+ .ops = &s2mps11_clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+ [S2MPS11_CLK_BT] = {
+ .name = "s2mps15_bt",
+ .ops = &s2mps11_clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+};
+
static struct device_node *s2mps11_clk_parse_dt(struct platform_device *pdev,
struct clk_init_data *clks_init)
{
@@ -207,6 +226,10 @@ static int s2mps11_clk_probe(struct platform_device *pdev)
s2mps11_reg = S2MPS14_REG_RTCCTRL;
clks_init = s2mps14_clks_init;
break;
+ case S2MPS15X:
+ s2mps11_reg = S2MPS15_REG_RTC_BUF;
+ clks_init = s2mps15_clks_init;
+ break;
case S5M8767X:
s2mps11_reg = S5M8767_REG_CTRL1;
clks_init = s2mps11_clks_init;
@@ -292,6 +315,7 @@ static const struct platform_device_id s2mps11_clk_id[] = {
{ "s2mps11-clk", S2MPS11X},
{ "s2mps13-clk", S2MPS13X},
{ "s2mps14-clk", S2MPS14X},
+ { "s2mps15-clk", S2MPS15X},
{ "s5m8767-clk", S5M8767X},
{ },
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/5] mfd: sec: Add support for S2MPS15 PMIC
Hi Lee,
Thanks for looking into this.
On 10/26/2015 04:36 PM, Lee Jones wrote:
On Mon, 26 Oct 2015, Alim Akhtar wrote:
From: Thomas Abraham
Add support for S2MPS15 PMIC which is similar to S2MPS11 PMIC. The S2MPS15
PMIC supports 27 LDO regulators, 10 buck regulators, RTC, three 32.768KHz
clock outputs and battery charger. This patch adds initial support for
LDO and buck regulators of S2MPS15 device.
Signed-off-by: Thomas Abraham
Signed-off-by: Alim Akhtar
[Alim: Added s2mps15_devs like rtc and clk and related changes]
Reviewed-by: Krzysztof Kozlowski
---
drivers/mfd/sec-core.c | 31 +++
drivers/mfd/sec-irq.c |8 ++
include/linux/mfd/samsung/core.h|1 +
include/linux/mfd/samsung/s2mps15.h | 161 +++
4 files changed, 201 insertions(+)
create mode 100644 include/linux/mfd/samsung/s2mps15.h
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 2626fc0b5b8c..db3d4d4ff805 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -96,6 +97,17 @@ static const struct mfd_cell s2mps14_devs[] = {
}
};
+static const struct mfd_cell s2mps15_devs[] = {
+ {
+ .name = "s2mps15-pmic",
+ }, {
+ .name = "s2mps15-rtc",
+ }, {
Why don't these have compatibles?
s2mps15-pmic does have compatible below in sec_dt_match[].
s2mps15-rtc does not need one as rtc driver does not support OF yet.
So no DT node for this as of now.
+ .name = "s2mps15-clk",
+ .of_compatible = "samsung,s2mps15-clk",
+ },
+};
+
static const struct mfd_cell s2mpa01_devs[] = {
{
.name = "s2mpa01-pmic",
@@ -125,6 +137,9 @@ static const struct of_device_id sec_dt_match[] = {
.compatible = "samsung,s2mps14-pmic",
.data = (void *)S2MPS14X,
}, {
+ .compatible = "samsung,s2mps15-pmic",
+ .data = (void *)S2MPS15X,
+ }, {
.compatible = "samsung,s2mpa01-pmic",
.data = (void *)S2MPA01,
}, {
@@ -226,6 +241,15 @@ static const struct regmap_config s2mps14_regmap_config = {
.cache_type = REGCACHE_FLAT,
};
+static const struct regmap_config s2mps15_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = S2MPS15_REG_LDODSCH4,
+ .volatile_reg = s2mps11_volatile,
+ .cache_type = REGCACHE_FLAT,
+};
+
static const struct regmap_config s2mpu02_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -387,6 +411,9 @@ static int sec_pmic_probe(struct i2c_client *i2c,
case S2MPS14X:
regmap = &s2mps14_regmap_config;
break;
+ case S2MPS15X:
+ regmap = &s2mps15_regmap_config;
+ break;
case S5M8763X:
regmap = &s5m8763_regmap_config;
break;
@@ -445,6 +472,10 @@ static int sec_pmic_probe(struct i2c_client *i2c,
sec_devs = s2mps14_devs;
num_sec_devs = ARRAY_SIZE(s2mps14_devs);
break;
+ case S2MPS15X:
+ sec_devs = s2mps15_devs;
+ num_sec_devs = ARRAY_SIZE(s2mps15_devs);
+ break;
case S2MPU02:
sec_devs = s2mpu02_devs;
num_sec_devs = ARRAY_SIZE(s2mpu02_devs);
diff --git a/drivers/mfd/sec-irq.c b/drivers/mfd/sec-irq.c
index 806fa8dbb22d..d77de431cc50 100644
--- a/drivers/mfd/sec-irq.c
+++ b/drivers/mfd/sec-irq.c
@@ -407,6 +407,11 @@ static const struct regmap_irq_chip s2mps14_irq_chip = {
S2MPS1X_IRQ_CHIP_COMMON_DATA,
};
+static const struct regmap_irq_chip s2mps15_irq_chip = {
+ .name = "s2mps15",
+ S2MPS1X_IRQ_CHIP_COMMON_DATA,
+};
+
static const struct regmap_irq_chip s2mpu02_irq_chip = {
.name = "s2mpu02",
.irqs = s2mpu02_irqs,
@@ -466,6 +471,9 @@ int sec_irq_init(struct sec_pmic_dev *sec_pmic)
case S2MPS14X:
sec_irq_chip = &s2mps14_irq_chip;
break;
+ case S2MPS15X:
+ sec_irq_chip = &s2mps15_irq_chip;
+ break;
case S2MPU02:
sec_irq_chip = &s2mpu02_irq_chip;
break;
diff --git a/include/linux/mfd/samsung/core.h b/include/linux/mfd/samsung/core.h
index a06098639399..6bc4bcd488ac 100644
--- a/include/linux/mfd/samsung/core.h
+++ b/include/linux/mfd/samsung/core.h
@@ -44,6 +44,7 @@ enum sec_device_type {
S2MPS11X,
S2MPS13X,
S2MPS14X,
+ S2MPS15X,
S2MPU02,
};
diff --git a/include/linux/mfd/samsung/s2mps15.h
b/include/linux/mfd/samsung/s2mps15.h
new file mode 100644
index ..7443af6a4bba
--- /dev/null
++
Re: [PATCH v2 1/5] dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC
On 10/26/2015 04:39 PM, Lee Jones wrote: On Mon, 26 Oct 2015, Alim Akhtar wrote: From: Thomas Abraham Add dt-binding documentation for s2mps15 PMIC device. The s2mps15 device is similar to s2mps11/14 PMIC device and has 27 LDO and 10 buck regulators. Cc: devicet...@vger.kernel.org Signed-off-by: Thomas Abraham Signed-off-by: Alim Akhtar Reviewed-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/mfd/s2mps11.txt | 23 ++--- 1 file changed, 15 insertions(+), 8 deletions(-) Nothing to controversial here. For my own reference: Acked-by: Lee Jones Thanks, will send v3 of this series. diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt index 890f0b0e1643..c0427c9d0886 100644 --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt @@ -1,5 +1,5 @@ -* Samsung S2MPS11, S2MPS13, S2MPS14 and S2MPU02 Voltage and Current Regulator +* Samsung S2MPS11/13/14/15 and S2MPU02 Voltage and Current Regulator The Samsung S2MPS11 is a multi-function device which includes voltage and current regulators, RTC, charger controller and other sub-blocks. It is @@ -7,8 +7,12 @@ interfaced to the host controller using an I2C interface. Each sub-block is addressed by the host system using different I2C slave addresses. Required properties: -- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps13-pmic" - or "samsung,s2mps14-pmic" or "samsung,s2mpu02-pmic". +- compatible: Should be one of the following + - "samsung,s2mps11-pmic" + - "samsung,s2mps13-pmic" + - "samsung,s2mps14-pmic" + - "samsung,s2mps15-pmic" + - "samsung,s2mpu02-pmic". - reg: Specifies the I2C slave address of the pmic block. It should be 0x66. Optional properties: @@ -24,7 +28,7 @@ Optional properties: unwanted buck warm reset (setting buck voltages to default values). Optional nodes: -- clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered 32.768 +- clocks: s2mps11, s2mps13, s2mps15 and s5m8767 provide three(AP/CP/BT) buffered 32.768 KHz outputs, so to register these as clocks with common clock framework instantiate a sub-node named "clocks". It uses the common clock binding documented in : @@ -37,12 +41,13 @@ Optional nodes: the clock which they consume. Clock ID Devices -- -32KhzAP0S2MPS11, S2MPS13, S2MPS14, S5M8767 -32KhzCP1S2MPS11, S2MPS13, S5M8767 -32KhzBT2S2MPS11, S2MPS13, S2MPS14, S5M8767 +32KhzAP0S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767 +32KhzCP1S2MPS11, S2MPS13, S2MPS15, S5M8767 +32KhzBT2S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767 - compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps13-clk", - "samsung,s2mps14-clk", "samsung,s5m8767-clk" + "samsung,s2mps14-clk", "samsung,s2mps15-clk", + "samsung,s5m8767-clk" - regulators: The regulators of s2mps11 that have to be instantiated should be included in a sub-node named 'regulators'. Regulator nodes included in this @@ -90,6 +95,7 @@ as per the datasheet of s2mps11. - S2MPS11: 1 to 38 - S2MPS13: 1 to 40 - S2MPS14: 1 to 25 + - S2MPS15: 1 to 27 - S2MPU02: 1 to 28 - Example: LDO1, LDO2, LDO28 - BUCKn @@ -97,6 +103,7 @@ as per the datasheet of s2mps11. - S2MPS11: 1 to 10 - S2MPS13: 1 to 10 - S2MPS14: 1 to 5 + - S2MPS15: 1 to 10 - S2MPU02: 1 to 7 - Example: BUCK1, BUCK2, BUCK9 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/5] mfd: sec: add S2MPS15 PMIC support
Samsung's S2MPS15 PMIC is targetted to be used with Samsung's Exynos7 SoC. The S2MPS15 PMIC is similar in functionality to S2MPS11/14 PMIC. It contains 27 LDO and 10 Buck regulators, RTC, three 32.768 KHz clock outputs and allows programming these blocks via a I2C interface. This patch series adds initial support for LDO/Buck regulators of S2MPS15 PMIC. Changes since v2: * Addressed Lee Jones review comments. Changes since v1: * Added suggestion from Krzysztof [1]. * Added s2mps15's 32.768 clocks support. * Added s2mps15's rtc support. V1 of these patches (with a lesser features) were posted a year back, since then there is not much progress on this, this is my attempt to move things forward. [1]-> https://lkml.org/lkml/2014/10/14/67 This series is based on linux-next-20151022. This is tested on exynos7-espresso board. Alim Akhtar (2): clk: s2mps15: Add support for S2MPS15 clocks drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC Thomas Abraham (3): dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC mfd: sec: Add support for S2MPS15 PMIC regulator: s2mps11: add support for S2MPS15 regulators Documentation/devicetree/bindings/mfd/s2mps11.txt | 23 +-- drivers/clk/Kconfig |5 +- drivers/clk/clk-s2mps11.c | 24 drivers/mfd/sec-core.c| 31 drivers/mfd/sec-irq.c |8 ++ drivers/regulator/Kconfig |4 +- drivers/regulator/s2mps11.c | 135 +- drivers/rtc/rtc-s5m.c | 14 +- include/linux/mfd/samsung/core.h |1 + include/linux/mfd/samsung/s2mps15.h | 158 + 10 files changed, 389 insertions(+), 14 deletions(-) create mode 100644 include/linux/mfd/samsung/s2mps15.h -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/5] dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC
From: Thomas Abraham Add dt-binding documentation for s2mps15 PMIC device. The s2mps15 device is similar to s2mps11/14 PMIC device and has 27 LDO and 10 buck regulators. Cc: devicet...@vger.kernel.org Signed-off-by: Thomas Abraham Signed-off-by: Alim Akhtar Reviewed-by: Krzysztof Kozlowski Acked-by: Lee Jones --- Documentation/devicetree/bindings/mfd/s2mps11.txt | 23 ++--- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt index 890f0b0e1643..c0427c9d0886 100644 --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt @@ -1,5 +1,5 @@ -* Samsung S2MPS11, S2MPS13, S2MPS14 and S2MPU02 Voltage and Current Regulator +* Samsung S2MPS11/13/14/15 and S2MPU02 Voltage and Current Regulator The Samsung S2MPS11 is a multi-function device which includes voltage and current regulators, RTC, charger controller and other sub-blocks. It is @@ -7,8 +7,12 @@ interfaced to the host controller using an I2C interface. Each sub-block is addressed by the host system using different I2C slave addresses. Required properties: -- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps13-pmic" - or "samsung,s2mps14-pmic" or "samsung,s2mpu02-pmic". +- compatible: Should be one of the following + - "samsung,s2mps11-pmic" + - "samsung,s2mps13-pmic" + - "samsung,s2mps14-pmic" + - "samsung,s2mps15-pmic" + - "samsung,s2mpu02-pmic". - reg: Specifies the I2C slave address of the pmic block. It should be 0x66. Optional properties: @@ -24,7 +28,7 @@ Optional properties: unwanted buck warm reset (setting buck voltages to default values). Optional nodes: -- clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered 32.768 +- clocks: s2mps11, s2mps13, s2mps15 and s5m8767 provide three(AP/CP/BT) buffered 32.768 KHz outputs, so to register these as clocks with common clock framework instantiate a sub-node named "clocks". It uses the common clock binding documented in : @@ -37,12 +41,13 @@ Optional nodes: the clock which they consume. Clock ID Devices -- -32KhzAP0S2MPS11, S2MPS13, S2MPS14, S5M8767 -32KhzCP1S2MPS11, S2MPS13, S5M8767 -32KhzBT2S2MPS11, S2MPS13, S2MPS14, S5M8767 +32KhzAP0S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767 +32KhzCP1S2MPS11, S2MPS13, S2MPS15, S5M8767 +32KhzBT2S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767 - compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps13-clk", - "samsung,s2mps14-clk", "samsung,s5m8767-clk" + "samsung,s2mps14-clk", "samsung,s2mps15-clk", + "samsung,s5m8767-clk" - regulators: The regulators of s2mps11 that have to be instantiated should be included in a sub-node named 'regulators'. Regulator nodes included in this @@ -90,6 +95,7 @@ as per the datasheet of s2mps11. - S2MPS11: 1 to 38 - S2MPS13: 1 to 40 - S2MPS14: 1 to 25 + - S2MPS15: 1 to 27 - S2MPU02: 1 to 28 - Example: LDO1, LDO2, LDO28 - BUCKn @@ -97,6 +103,7 @@ as per the datasheet of s2mps11. - S2MPS11: 1 to 10 - S2MPS13: 1 to 10 - S2MPS14: 1 to 5 + - S2MPS15: 1 to 10 - S2MPU02: 1 to 7 - Example: BUCK1, BUCK2, BUCK9 -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/5] mfd: sec: Add support for S2MPS15 PMIC
From: Thomas Abraham
Add support for S2MPS15 PMIC which is similar to S2MPS11 PMIC. The S2MPS15
PMIC supports 27 LDO regulators, 10 buck regulators, RTC, three 32.768KHz
clock outputs and battery charger. This patch adds initial support for
LDO and buck regulators of S2MPS15 device.
Signed-off-by: Thomas Abraham
Signed-off-by: Alim Akhtar
[Alim: Added s2mps15_devs like rtc and clk and related changes]
Reviewed-by: Krzysztof Kozlowski
---
drivers/mfd/sec-core.c | 31 +++
drivers/mfd/sec-irq.c |8 ++
include/linux/mfd/samsung/core.h|1 +
include/linux/mfd/samsung/s2mps15.h | 158 +++
4 files changed, 198 insertions(+)
create mode 100644 include/linux/mfd/samsung/s2mps15.h
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 2626fc0b5b8c..db3d4d4ff805 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -96,6 +97,17 @@ static const struct mfd_cell s2mps14_devs[] = {
}
};
+static const struct mfd_cell s2mps15_devs[] = {
+ {
+ .name = "s2mps15-pmic",
+ }, {
+ .name = "s2mps15-rtc",
+ }, {
+ .name = "s2mps15-clk",
+ .of_compatible = "samsung,s2mps15-clk",
+ },
+};
+
static const struct mfd_cell s2mpa01_devs[] = {
{
.name = "s2mpa01-pmic",
@@ -125,6 +137,9 @@ static const struct of_device_id sec_dt_match[] = {
.compatible = "samsung,s2mps14-pmic",
.data = (void *)S2MPS14X,
}, {
+ .compatible = "samsung,s2mps15-pmic",
+ .data = (void *)S2MPS15X,
+ }, {
.compatible = "samsung,s2mpa01-pmic",
.data = (void *)S2MPA01,
}, {
@@ -226,6 +241,15 @@ static const struct regmap_config s2mps14_regmap_config = {
.cache_type = REGCACHE_FLAT,
};
+static const struct regmap_config s2mps15_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = S2MPS15_REG_LDODSCH4,
+ .volatile_reg = s2mps11_volatile,
+ .cache_type = REGCACHE_FLAT,
+};
+
static const struct regmap_config s2mpu02_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -387,6 +411,9 @@ static int sec_pmic_probe(struct i2c_client *i2c,
case S2MPS14X:
regmap = &s2mps14_regmap_config;
break;
+ case S2MPS15X:
+ regmap = &s2mps15_regmap_config;
+ break;
case S5M8763X:
regmap = &s5m8763_regmap_config;
break;
@@ -445,6 +472,10 @@ static int sec_pmic_probe(struct i2c_client *i2c,
sec_devs = s2mps14_devs;
num_sec_devs = ARRAY_SIZE(s2mps14_devs);
break;
+ case S2MPS15X:
+ sec_devs = s2mps15_devs;
+ num_sec_devs = ARRAY_SIZE(s2mps15_devs);
+ break;
case S2MPU02:
sec_devs = s2mpu02_devs;
num_sec_devs = ARRAY_SIZE(s2mpu02_devs);
diff --git a/drivers/mfd/sec-irq.c b/drivers/mfd/sec-irq.c
index 806fa8dbb22d..d77de431cc50 100644
--- a/drivers/mfd/sec-irq.c
+++ b/drivers/mfd/sec-irq.c
@@ -407,6 +407,11 @@ static const struct regmap_irq_chip s2mps14_irq_chip = {
S2MPS1X_IRQ_CHIP_COMMON_DATA,
};
+static const struct regmap_irq_chip s2mps15_irq_chip = {
+ .name = "s2mps15",
+ S2MPS1X_IRQ_CHIP_COMMON_DATA,
+};
+
static const struct regmap_irq_chip s2mpu02_irq_chip = {
.name = "s2mpu02",
.irqs = s2mpu02_irqs,
@@ -466,6 +471,9 @@ int sec_irq_init(struct sec_pmic_dev *sec_pmic)
case S2MPS14X:
sec_irq_chip = &s2mps14_irq_chip;
break;
+ case S2MPS15X:
+ sec_irq_chip = &s2mps15_irq_chip;
+ break;
case S2MPU02:
sec_irq_chip = &s2mpu02_irq_chip;
break;
diff --git a/include/linux/mfd/samsung/core.h b/include/linux/mfd/samsung/core.h
index a06098639399..6bc4bcd488ac 100644
--- a/include/linux/mfd/samsung/core.h
+++ b/include/linux/mfd/samsung/core.h
@@ -44,6 +44,7 @@ enum sec_device_type {
S2MPS11X,
S2MPS13X,
S2MPS14X,
+ S2MPS15X,
S2MPU02,
};
diff --git a/include/linux/mfd/samsung/s2mps15.h
b/include/linux/mfd/samsung/s2mps15.h
new file mode 100644
index ..36d35287c3c0
--- /dev/null
+++ b/include/linux/mfd/samsung/s2mps15.h
@@ -0,0 +1,158 @@
+/*
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation;
[PATCH v3 3/5] regulator: s2mps11: add support for S2MPS15 regulators
From: Thomas Abraham
The S2MPS15 PMIC is similar in functionality to S2MPS11/14 PMIC. It contains
27 LDO and 10 Buck regulators and allows programming these regulators via a
I2C interface. This patch adds initial support for LDO/Buck regulators of
S2MPS15 PMIC.
Signed-off-by: Thomas Abraham
Signed-off-by: Alim Akhtar
Reviewed-by: Krzysztof Kozlowski
---
drivers/regulator/Kconfig |4 +-
drivers/regulator/s2mps11.c | 135 ++-
2 files changed, 136 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 64bccff557be..3e3ee5b88b3f 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -588,10 +588,10 @@ config REGULATOR_S2MPA01
via I2C bus. S2MPA01 has 10 Bucks and 26 LDO outputs.
config REGULATOR_S2MPS11
- tristate "Samsung S2MPS11/S2MPS13/S2MPS14/S2MPU02 voltage regulator"
+ tristate "Samsung S2MPS11/13/14/15/S2MPU02 voltage regulator"
depends on MFD_SEC_CORE
help
-This driver supports a Samsung S2MPS11/S2MPS13/S2MPS14/S2MPU02 voltage
+This driver supports a Samsung S2MPS11/13/14/15/S2MPU02 voltage
output regulator via I2C bus. The chip is comprised of high efficient
Buck converters including Dual-Phase Buck converter, Buck-Boost
converter, various LDOs.
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index 72fc3c32db49..12c59158552c 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
/* The highest number of possible regulators for supported devices. */
@@ -661,6 +662,133 @@ static const struct regulator_desc s2mps14_regulators[] =
{
S2MPS14_BUCK1235_START_SEL),
};
+static struct regulator_ops s2mps15_reg_ldo_ops = {
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage= regulator_map_voltage_linear_range,
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = regulator_enable_regmap,
+ .disable= regulator_disable_regmap,
+ .get_voltage_sel= regulator_get_voltage_sel_regmap,
+ .set_voltage_sel= regulator_set_voltage_sel_regmap,
+};
+
+static struct regulator_ops s2mps15_reg_buck_ops = {
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage= regulator_map_voltage_linear_range,
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = regulator_enable_regmap,
+ .disable= regulator_disable_regmap,
+ .get_voltage_sel= regulator_get_voltage_sel_regmap,
+ .set_voltage_sel= regulator_set_voltage_sel_regmap,
+ .set_voltage_time_sel = regulator_set_voltage_time_sel,
+};
+
+#define regulator_desc_s2mps15_ldo(num, range) { \
+ .name = "LDO"#num,\
+ .id = S2MPS15_LDO##num, \
+ .ops= &s2mps15_reg_ldo_ops, \
+ .type = REGULATOR_VOLTAGE,\
+ .owner = THIS_MODULE, \
+ .linear_ranges = range,\
+ .n_linear_ranges = ARRAY_SIZE(range), \
+ .n_voltages = S2MPS15_LDO_N_VOLTAGES, \
+ .vsel_reg = S2MPS15_REG_L1CTRL + num - 1, \
+ .vsel_mask = S2MPS15_LDO_VSEL_MASK,\
+ .enable_reg = S2MPS15_REG_L1CTRL + num - 1, \
+ .enable_mask= S2MPS15_ENABLE_MASK \
+}
+
+#define regulator_desc_s2mps15_buck(num, range) { \
+ .name = "BUCK"#num, \
+ .id = S2MPS15_BUCK##num,\
+ .ops= &s2mps15_reg_buck_ops,\
+ .type = REGULATOR_VOLTAGE,\
+ .owner = THIS_MODULE, \
+ .linear_ranges = range,\
+ .n_linear_ranges = ARRAY_SIZE(range), \
+ .ramp_delay = 12500,\
+ .n_voltages = S2MPS15_BUCK_N_VOLTAGES, \
+ .vsel_reg = S2MPS15_REG_B1CTRL2 + ((num - 1) * 2),\
+ .vsel_mask = S2MPS15_BUCK_VSEL_MASK, \
+ .enable_reg = S2MPS15_REG_B1CTRL1 + ((num - 1) * 2),\
+ .enable_mask= S2MPS15_ENABLE_MASK \
+}
+
+/* voltage range for s2mps15 LDO 3, 5, 15, 16, 18, 20, 23 and 27 */
+static const struct regulator_linear_range s2mps15_ldo_voltage_ranges1[] = {
+ REGULATOR_LINEAR_RANGE(100, 0xc, 0
[PATCH v3 4/5] clk: s2mps15: Add support for S2MPS15 clocks
S2MPS15 PMIC has three 32k buffered clocks outputs. This patch
adds supports for the same to the s2mps11 clock driver.
Signed-off-by: Alim Akhtar
---
drivers/clk/Kconfig |5 +++--
drivers/clk/clk-s2mps11.c | 24
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index a1fa61159179..037a314b5d76 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -120,9 +120,10 @@ config COMMON_CLK_S2MPS11
tristate "Clock driver for S2MPS1X/S5M8767 MFD"
depends on MFD_SEC_CORE
---help---
- This driver supports S2MPS11/S2MPS14/S5M8767 crystal oscillator
+ This driver supports S2MPS1X/S5M8767 crystal oscillator
clock. These multi-function devices have two (S2MPS14) or three
- (S2MPS11, S5M8767) fixed-rate oscillators, clocked at 32KHz each.
+ (S2MPS11/S2MPS13/S2MPS15/S5M8767) fixed-rate oscillators,
+ clocked at 32KHz each.
config CLK_TWL6040
tristate "External McPDM functional clock from twl6040"
diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
index d266299dfdb1..455500dca653 100644
--- a/drivers/clk/clk-s2mps11.c
+++ b/drivers/clk/clk-s2mps11.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -148,6 +149,24 @@ static struct clk_init_data
s2mps14_clks_init[S2MPS11_CLKS_NUM] = {
},
};
+static struct clk_init_data s2mps15_clks_init[S2MPS11_CLKS_NUM] = {
+ [S2MPS11_CLK_AP] = {
+ .name = "s2mps15_ap",
+ .ops = &s2mps11_clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+ [S2MPS11_CLK_CP] = {
+ .name = "s2mps15_cp",
+ .ops = &s2mps11_clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+ [S2MPS11_CLK_BT] = {
+ .name = "s2mps15_bt",
+ .ops = &s2mps11_clk_ops,
+ .flags = CLK_IS_ROOT,
+ },
+};
+
static struct device_node *s2mps11_clk_parse_dt(struct platform_device *pdev,
struct clk_init_data *clks_init)
{
@@ -207,6 +226,10 @@ static int s2mps11_clk_probe(struct platform_device *pdev)
s2mps11_reg = S2MPS14_REG_RTCCTRL;
clks_init = s2mps14_clks_init;
break;
+ case S2MPS15X:
+ s2mps11_reg = S2MPS15_REG_RTC_BUF;
+ clks_init = s2mps15_clks_init;
+ break;
case S5M8767X:
s2mps11_reg = S5M8767_REG_CTRL1;
clks_init = s2mps11_clks_init;
@@ -292,6 +315,7 @@ static const struct platform_device_id s2mps11_clk_id[] = {
{ "s2mps11-clk", S2MPS11X},
{ "s2mps13-clk", S2MPS13X},
{ "s2mps14-clk", S2MPS14X},
+ { "s2mps15-clk", S2MPS15X},
{ "s5m8767-clk", S5M8767X},
{ },
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 5/5] drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC
RTC found in s2mps15 is almost same as one found in s2mps14.
This patch add required changes to enable s2mps15 rtc timer.
Signed-off-by: Alim Akhtar
---
drivers/rtc/rtc-s5m.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index f2504b4eef34..ac3286a267ba 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -188,6 +188,7 @@ static inline int s5m_check_peding_alarm_interrupt(struct
s5m_rtc_info *info,
ret = regmap_read(info->regmap, S5M_RTC_STATUS, &val);
val &= S5M_ALARM0_STATUS;
break;
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
ret = regmap_read(info->s5m87xx->regmap_pmic, S2MPS14_REG_ST2,
@@ -253,6 +254,7 @@ static inline int s5m8767_rtc_set_alarm_reg(struct
s5m_rtc_info *info)
data &= ~S5M_RTC_TIME_EN_MASK;
break;
case S2MPS14X:
+ case S2MPS15X:
data |= S2MPS_RTC_RUDR_MASK;
break;
case S2MPS13X:
@@ -317,7 +319,8 @@ static int s5m_rtc_read_time(struct device *dev, struct
rtc_time *tm)
u8 data[info->regs->regs_count];
int ret;
- if (info->device_type == S2MPS14X || info->device_type == S2MPS13X) {
+ if (info->device_type == S2MPS14X || info->device_type == S2MPS15X ||
+ info->device_type == S2MPS13X) {
ret = regmap_update_bits(info->regmap,
info->regs->rtc_udr_update,
S2MPS_RTC_RUDR_MASK, S2MPS_RTC_RUDR_MASK);
@@ -339,6 +342,7 @@ static int s5m_rtc_read_time(struct device *dev, struct
rtc_time *tm)
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
s5m8767_data_to_tm(data, tm, info->rtc_24hr_mode);
@@ -366,6 +370,7 @@ static int s5m_rtc_set_time(struct device *dev, struct
rtc_time *tm)
s5m8763_tm_to_data(tm, data);
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
ret = s5m8767_tm_to_data(tm, data);
@@ -414,6 +419,7 @@ static int s5m_rtc_read_alarm(struct device *dev, struct
rtc_wkalrm *alrm)
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
s5m8767_data_to_tm(data, &alrm->time, info->rtc_24hr_mode);
@@ -463,6 +469,7 @@ static int s5m_rtc_stop_alarm(struct s5m_rtc_info *info)
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
for (i = 0; i < info->regs->regs_count; i++)
@@ -508,6 +515,7 @@ static int s5m_rtc_start_alarm(struct s5m_rtc_info *info)
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
data[RTC_SEC] |= ALARM_ENABLE_MASK;
@@ -548,6 +556,7 @@ static int s5m_rtc_set_alarm(struct device *dev, struct
rtc_wkalrm *alrm)
break;
case S5M8767X:
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
s5m8767_tm_to_data(&alrm->time, data);
@@ -631,6 +640,7 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info *info)
ret = regmap_raw_write(info->regmap, S5M_ALARM0_CONF, data, 2);
break;
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
data[0] = (0 << BCD_EN_SHIFT) | (1 << MODEL24_SHIFT);
@@ -679,6 +689,7 @@ static int s5m_rtc_probe(struct platform_device *pdev)
return -ENOMEM;
switch (platform_get_device_id(pdev)->driver_data) {
+ case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
regmap_cfg = &s2mps14_rtc_regmap_config;
@@ -805,6 +816,7 @@ static const struct platform_device_id s5m_rtc_id[] = {
{ "s5m-rtc",S5M8767X },
{ "s2mps13-rtc",S2MPS13X },
{ "s2mps14-rtc",S2MPS14X },
+ { "s2mps15-rtc",S2MPS15X },
{ },
};
MODULE_DEVICE_TABLE(platform, s5m_rtc_id);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/5] mfd: sec: Add support for S2MPS15 PMIC
Hello
On 10/26/2015 07:59 PM, Lee Jones wrote:
On Mon, 26 Oct 2015, Alim Akhtar wrote:
Hi Lee,
Thanks for looking into this.
On 10/26/2015 04:36 PM, Lee Jones wrote:
On Mon, 26 Oct 2015, Alim Akhtar wrote:
From: Thomas Abraham
Add support for S2MPS15 PMIC which is similar to S2MPS11 PMIC. The S2MPS15
PMIC supports 27 LDO regulators, 10 buck regulators, RTC, three 32.768KHz
clock outputs and battery charger. This patch adds initial support for
LDO and buck regulators of S2MPS15 device.
Signed-off-by: Thomas Abraham
Signed-off-by: Alim Akhtar
[Alim: Added s2mps15_devs like rtc and clk and related changes]
Reviewed-by: Krzysztof Kozlowski
---
drivers/mfd/sec-core.c | 31 +++
drivers/mfd/sec-irq.c |8 ++
include/linux/mfd/samsung/core.h|1 +
include/linux/mfd/samsung/s2mps15.h | 161 +++
4 files changed, 201 insertions(+)
create mode 100644 include/linux/mfd/samsung/s2mps15.h
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 2626fc0b5b8c..db3d4d4ff805 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -96,6 +97,17 @@ static const struct mfd_cell s2mps14_devs[] = {
}
};
+static const struct mfd_cell s2mps15_devs[] = {
+ {
+ .name = "s2mps15-pmic",
+ }, {
+ .name = "s2mps15-rtc",
+ }, {
Why don't these have compatibles?
s2mps15-pmic does have compatible below in sec_dt_match[].
Woah!! What's going on here? You're matching the MFD and Regulator
drivers with the same compatible string. And then registering the
Regulator device as an MFD. That's a bit confusing don't you think?
Sorry for the confusion, as explained in the binding documentation,
S2MPS15 is a multi-function device which has rtc, regulator and clk
provider as a sub-blocks. And each of these sub-blocks are represented
as child node of parent MFD node. Out of these only clk controller child
node needs its own compatible string to populate of_node structure of
the device so that it can access properties of this sub-node in
drivers/clk/clk-s2mps11.c.
I just followed "Documentation/devicetree/bindings/mfd/s2mps11.txt"
to implement s2mps15.
s2mps15-rtc does not need one as rtc driver does not support OF yet.
So no DT node for this as of now.
[...]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 00/13] exynos-ufs: add support for Exynos
This patch-set introduces UFS (Universal Flash Storage) host support for Samsung Exynos SoC. Mostly, it consists of UFS PHY and host specific driver. And it also contains some quirks handling for Exynos. -Chanes since v2: * Addressed review comments from Kishon[1] and Rob Herring [2] * Splited ufs dt binding documetation from ufs driver patch -Changes since v1: * Addressed review comments from Alexey[3] and various review comments from Amit. * Updated email id of Seungwon as his samsung id is void now. * Added ufs platform data [1]-> https://lkml.org/lkml/2015/9/18/29 [2]-> https://lkml.org/lkml/2015/9/21/668 [3]-> https://lkml.org/lkml/2015/8/23/124 This patch set is tested on exynos7-espresso board. Alim Akhtar (2): Documentation: samsung-phy: Add dt bindings for UFS scsi: ufs: Add exynos ufs platform data Seungwon Jeon (11): phy: exynos-ufs: add UFS PHY driver for EXYNOS SoC scsi: ufs: add quirk to contain unconformable utrd field scsi: ufs: add quirk to fix mishandling utrlclr/utmrlclr scsi: ufs: add quirk not to allow reset of interrupt aggregation scsi: ufs: add quirk to enable host controller without hce scsi: ufs: add specific callback for nexus type scsi: ufs: add add specific callback for hibern8 scsi: ufs: make ufshcd_config_pwr_mode of non-static func scsi: ufs: return value of pwr_change_notify Documentation: devicetree: ufs: Add DT bindings for exynos UFS host controller scsi: ufs-exynos: add UFS host support for Exynos SoCs .../devicetree/bindings/phy/samsung-phy.txt| 22 + .../devicetree/bindings/ufs/ufs-exynos.txt | 93 ++ drivers/phy/Kconfig|7 + drivers/phy/Makefile |1 + drivers/phy/phy-exynos-ufs.c | 257 + drivers/phy/phy-exynos-ufs.h | 87 ++ drivers/phy/phy-exynos7-ufs.h | 89 ++ drivers/scsi/ufs/Kconfig | 12 + drivers/scsi/ufs/Makefile |1 + drivers/scsi/ufs/ufs-exynos-hw.c | 147 +++ drivers/scsi/ufs/ufs-exynos-hw.h | 43 + drivers/scsi/ufs/ufs-exynos.c | 1186 drivers/scsi/ufs/ufs-exynos.h | 463 drivers/scsi/ufs/ufshcd-pltfrm.c |2 + drivers/scsi/ufs/ufshcd.c | 196 +++- drivers/scsi/ufs/ufshcd.h | 35 + drivers/scsi/ufs/ufshci.h | 26 +- drivers/scsi/ufs/unipro.h | 47 + include/linux/phy/phy-exynos-ufs.h | 101 ++ 19 files changed, 2788 insertions(+), 27 deletions(-) create mode 100644 Documentation/devicetree/bindings/ufs/ufs-exynos.txt create mode 100644 drivers/phy/phy-exynos-ufs.c create mode 100644 drivers/phy/phy-exynos-ufs.h create mode 100644 drivers/phy/phy-exynos7-ufs.h create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.c create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.h create mode 100644 drivers/scsi/ufs/ufs-exynos.c create mode 100644 drivers/scsi/ufs/ufs-exynos.h create mode 100644 include/linux/phy/phy-exynos-ufs.h -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 01/13] Documentation: samsung-phy: Add dt bindings for UFS
Adds exynos UFS PHY device tree bindings information.
Signed-off-by: Alim Akhtar
---
.../devicetree/bindings/phy/samsung-phy.txt| 22
1 file changed, 22 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 60c6f2a..c92ce53 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -174,3 +174,25 @@ Example:
usbdrdphy0 = &usb3_phy0;
usbdrdphy1 = &usb3_phy1;
};
+
+Samsung Exynos7 soc series UFS PHY Controller
+-
+
+UFS PHY nodes are defined to describe on-chip UFS Physical layer controllers.
+Each UFS PHY controller should have its own node.
+
+Required properties:
+- compatible: compatible should be set to "samsung,exynos7-ufs-phy"
+- reg : offset and length of the UFS PHY register set
+- reg-names : reg name(s) must be 'phy-pma'
+- #phy-cells : must be zero
+- samsung,pmu-syscon : a phandle to the PMU system controller, no arguments
+
+Example:
+ ufs_phy: ufs-phy@0x15571800 {
+ compatible = "samsung,exynos7-ufs-phy";
+ reg = <0x15571800 0x240>;
+ reg-names = "phy-pma";
+ samsung,pmu-syscon = <&pmu_system_controller>;
+ #phy-cells = <0>;
+ };
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 02/13] phy: exynos-ufs: add UFS PHY driver for EXYNOS SoC
From: Seungwon Jeon
This patch introduces Exynos UFS PHY driver. This driver
supports to deal with phy calibration and power control
according to UFS host driver's behavior.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
Cc: Kishon Vijay Abraham I
---
drivers/phy/Kconfig|7 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos-ufs.c | 257
drivers/phy/phy-exynos-ufs.h | 88
drivers/phy/phy-exynos7-ufs.h | 89 +
include/linux/phy/phy-exynos-ufs.h | 101 ++
6 files changed, 543 insertions(+)
create mode 100644 drivers/phy/phy-exynos-ufs.c
create mode 100644 drivers/phy/phy-exynos-ufs.h
create mode 100644 drivers/phy/phy-exynos7-ufs.h
create mode 100644 include/linux/phy/phy-exynos-ufs.h
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 6b8dd16..199a865 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -358,4 +358,11 @@ config PHY_BRCMSTB_SATA
Enable this to support the SATA3 PHY on 28nm Broadcom STB SoCs.
Likely useful only with CONFIG_SATA_BRCMSTB enabled.
+config PHY_EXYNOS_UFS
+ tristate "EXYNOS SoC series UFS PHY driver"
+ depends on OF && ARCH_EXYNOS || COMPILE_TEST
+ select GENERIC_PHY
+ help
+ Support for UFS PHY on Samsung EXYNOS chipsets.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index f344e1b..7a36818 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -45,3 +45,4 @@ obj-$(CONFIG_PHY_QCOM_UFS)+= phy-qcom-ufs-qmp-14nm.o
obj-$(CONFIG_PHY_TUSB1210) += phy-tusb1210.o
obj-$(CONFIG_PHY_BRCMSTB_SATA) += phy-brcmstb-sata.o
obj-$(CONFIG_PHY_PISTACHIO_USB)+= phy-pistachio-usb.o
+obj-$(CONFIG_PHY_EXYNOS_UFS) += phy-exynos-ufs.o
diff --git a/drivers/phy/phy-exynos-ufs.c b/drivers/phy/phy-exynos-ufs.c
new file mode 100644
index 000..343fcaf
--- /dev/null
+++ b/drivers/phy/phy-exynos-ufs.c
@@ -0,0 +1,257 @@
+/*
+ * UFS PHY driver for Samsung EXYNOS SoC
+ *
+ * Copyright (C) 2015 Samsung Electronics Co., Ltd.
+ * Author: Seungwon Jeon
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "phy-exynos-ufs.h"
+
+#define for_each_phy_lane(phy, i) \
+ for (i = 0; i < (phy)->lane_cnt; i++)
+#define for_each_phy_cfg(cfg) \
+ for (; (cfg)->id; (cfg)++)
+
+#define PHY_DEF_LANE_CNT 1
+
+static void exynos_ufs_phy_config(struct exynos_ufs_phy *phy,
+ const struct exynos_ufs_phy_cfg *cfg, u8 lane)
+{
+ enum {LANE_0, LANE_1}; /* lane index */
+
+ switch (lane) {
+ case LANE_0:
+ writel(cfg->val, (phy)->reg_pma + cfg->off_0);
+ break;
+ case LANE_1:
+ if (cfg->id == PHY_TRSV_BLK)
+ writel(cfg->val, (phy)->reg_pma + cfg->off_1);
+ break;
+ }
+}
+
+static bool match_cfg_to_pwr_mode(u8 desc, u8 required_pwr)
+{
+ if (IS_PWR_MODE_ANY(desc))
+ return true;
+
+ if (IS_PWR_MODE_HS(required_pwr) && IS_PWR_MODE_HS_ANY(desc))
+ return true;
+
+ if (COMP_PWR_MODE(required_pwr, desc))
+ return true;
+
+ if (COMP_PWR_MODE_MD(required_pwr, desc) &&
+ COMP_PWR_MODE_GEAR(required_pwr, desc) &&
+ COMP_PWR_MODE_SER(required_pwr, desc))
+ return true;
+
+ return false;
+}
+
+int exynos_ufs_phy_calibrate(struct phy *phy, enum phy_cfg_tag tag, u8 pwr)
+{
+ struct exynos_ufs_phy *ufs_phy = get_exynos_ufs_phy(phy);
+ struct exynos_ufs_phy_cfg **cfgs = ufs_phy->cfg;
+ const struct exynos_ufs_phy_cfg *cfg;
+ int i;
+
+ if (unlikely(tag < CFG_PRE_INIT || tag >= CFG_TAG_MAX)) {
+ dev_err(ufs_phy->dev, "invalid phy config index %d\n", tag);
+ return -EINVAL;
+ }
+
+ cfg = cfgs[tag];
+ if (!cfg)
+ goto out;
+
+ for_each_phy_cfg(cfg) {
+ for_each_phy_lane(ufs_phy, i) {
+ if (match_cfg_to_pwr_mode(cfg->desc, pwr))
+ exynos_ufs_phy_config(ufs_phy, cfg, i);
+ }
+ }
+
+out:
+ return 0;
+}
+
+void exynos_ufs_phy_set_lane_cnt(struct phy *phy, u8 lane_cnt)
+{
+ struct exynos_ufs_phy *ufs_phy = get_exynos_ufs_phy(phy);
+
+ ufs_phy->lane_cnt = lane_cnt;
+}
+
+int exynos_ufs_phy_wait_for_lock_acq(struct phy *phy)
+{
+ struct exynos_ufs
[PATCH v3 04/13] scsi: ufs: add quirk to fix mishandling utrlclr/utmrlclr
From: Seungwon Jeon
In the right behavior, setting the bit to '0' indicates clear and
'1' indicates no change. If host contoller handles this the other way,
UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR can be used.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c | 21 +++--
drivers/scsi/ufs/ufshcd.h |5 +
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 90f76e7..d41d57d 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -358,7 +358,24 @@ static inline void ufshcd_put_tm_slot(struct ufs_hba *hba,
int slot)
*/
static inline void ufshcd_utrl_clear(struct ufs_hba *hba, u32 pos)
{
- ufshcd_writel(hba, ~(1 << pos), REG_UTP_TRANSFER_REQ_LIST_CLEAR);
+ if (hba->quirks & UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR)
+ ufshcd_writel(hba, (1 << pos), REG_UTP_TRANSFER_REQ_LIST_CLEAR);
+ else
+ ufshcd_writel(hba, ~(1 << pos),
+ REG_UTP_TRANSFER_REQ_LIST_CLEAR);
+}
+
+/**
+ * ufshcd_utmrl_clear - Clear a bit in UTRMLCLR register
+ * @hba: per adapter instance
+ * @pos: position of the bit to be cleared
+ */
+static inline void ufshcd_utmrl_clear(struct ufs_hba *hba, u32 pos)
+{
+ if (hba->quirks & UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR)
+ ufshcd_writel(hba, (1 << pos), REG_UTP_TASK_REQ_LIST_CLEAR);
+ else
+ ufshcd_writel(hba, ~(1 << pos), REG_UTP_TASK_REQ_LIST_CLEAR);
}
/**
@@ -3691,7 +3708,7 @@ static int ufshcd_clear_tm_cmd(struct ufs_hba *hba, int
tag)
goto out;
spin_lock_irqsave(hba->host->host_lock, flags);
- ufshcd_writel(hba, ~(1 << tag), REG_UTP_TASK_REQ_LIST_CLEAR);
+ ufshcd_utmrl_clear(hba, tag);
spin_unlock_irqrestore(hba->host->host_lock, flags);
/* poll for max. 1 sec to clear door bell register by h/w */
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 2f96abe..3702b92 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -466,6 +466,11 @@ struct ufs_hba {
*/
#define UFSHCI_QUIRK_BYTE_ALIGN_UTRDUFS_BIT(6)
+ /*
+* Cleaer handling for transfer/task request list is just opposite.
+*/
+ #define UFSHCI_QUIRK_BROKEN_REQ_LIST_CLRUFS_BIT(7)
+
unsigned int quirks;/* Deviations from standard UFSHCI spec. */
wait_queue_head_t tm_wq;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 03/13] scsi: ufs: add quirk to contain unconformable utrd field
From: Seungwon Jeon
UTRD(UTP Transfer Request Descriptor)'s field such as offset/length,
especially response's has DWORD expression. This quirk can be specified
for host controller not to conform standard.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c | 28 +---
drivers/scsi/ufs/ufshcd.h |7 +++
2 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index b0ade73..90f76e7 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1009,7 +1009,7 @@ ufshcd_send_uic_cmd(struct ufs_hba *hba, struct
uic_command *uic_cmd)
*
* Returns 0 in case of success, non-zero value in case of failure
*/
-static int ufshcd_map_sg(struct ufshcd_lrb *lrbp)
+static int ufshcd_map_sg(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
{
struct ufshcd_sg_entry *prd_table;
struct scatterlist *sg;
@@ -1023,8 +1023,13 @@ static int ufshcd_map_sg(struct ufshcd_lrb *lrbp)
return sg_segments;
if (sg_segments) {
- lrbp->utr_descriptor_ptr->prd_table_length =
- cpu_to_le16((u16) (sg_segments));
+ if (hba->quirks & UFSHCI_QUIRK_BYTE_ALIGN_UTRD)
+ lrbp->utr_descriptor_ptr->prd_table_length =
+ cpu_to_le16((u16)(sg_segments *
+ sizeof(struct ufshcd_sg_entry)));
+ else
+ lrbp->utr_descriptor_ptr->prd_table_length =
+ cpu_to_le16((u16) (sg_segments));
prd_table = (struct ufshcd_sg_entry *)lrbp->ucd_prdt_ptr;
@@ -1347,7 +1352,7 @@ static int ufshcd_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *cmd)
/* form UPIU before issuing the command */
ufshcd_compose_upiu(hba, lrbp);
- err = ufshcd_map_sg(lrbp);
+ err = ufshcd_map_sg(hba, lrbp);
if (err) {
lrbp->cmd = NULL;
clear_bit_unlock(tag, &hba->lrb_in_use);
@@ -2034,13 +2039,22 @@ static void ufshcd_host_memory_configure(struct ufs_hba
*hba)
utrdlp[i].command_desc_base_addr_hi =
cpu_to_le32(upper_32_bits(cmd_desc_element_addr));
+ if (hba->quirks & UFSHCI_QUIRK_BYTE_ALIGN_UTRD) {
+ utrdlp[i].response_upiu_offset =
+ cpu_to_le16(response_offset);
+ utrdlp[i].prd_table_offset =
+ cpu_to_le16(prdt_offset);
+ utrdlp[i].response_upiu_length =
+ cpu_to_le16(ALIGNED_UPIU_SIZE);
+ } else {
/* Response upiu and prdt offset should be in double words */
- utrdlp[i].response_upiu_offset =
+ utrdlp[i].response_upiu_offset =
cpu_to_le16((response_offset >> 2));
- utrdlp[i].prd_table_offset =
+ utrdlp[i].prd_table_offset =
cpu_to_le16((prdt_offset >> 2));
- utrdlp[i].response_upiu_length =
+ utrdlp[i].response_upiu_length =
cpu_to_le16(ALIGNED_UPIU_SIZE >> 2);
+ }
hba->lrb[i].utr_descriptor_ptr = (utrdlp + i);
hba->lrb[i].ucd_req_ptr =
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index c40a0e7..2f96abe 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -459,6 +459,13 @@ struct ufs_hba {
*/
#define UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION UFS_BIT(5)
+ /*
+* This quirk needs to be enabled if host controller doesn't conform
+* with UTRD. Some fields such as offset/length might not be in double
+* word, but in byte.
+*/
+ #define UFSHCI_QUIRK_BYTE_ALIGN_UTRDUFS_BIT(6)
+
unsigned int quirks;/* Deviations from standard UFSHCI spec. */
wait_queue_head_t tm_wq;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 06/13] scsi: ufs: add quirk to enable host controller without hce
From: Seungwon Jeon
Some host controller doesn't support host controller enable via HCE.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c | 76 +++--
drivers/scsi/ufs/ufshcd.h |5 +++
2 files changed, 79 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index e388edc..07659be 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -2107,6 +2107,52 @@ static int ufshcd_dme_link_startup(struct ufs_hba *hba)
"dme-link-startup: error code %d\n", ret);
return ret;
}
+/**
+ * ufshcd_dme_reset - UIC command for DME_RESET
+ * @hba: per adapter instance
+ *
+ * DME_RESET command is issued in order to reset UniPro stack.
+ * This function now deal with cold reset.
+ *
+ * Returns 0 on success, non-zero value on failure
+ */
+static int ufshcd_dme_reset(struct ufs_hba *hba)
+{
+ struct uic_command uic_cmd = {0};
+ int ret;
+
+ uic_cmd.command = UIC_CMD_DME_RESET;
+
+ ret = ufshcd_send_uic_cmd(hba, &uic_cmd);
+ if (ret)
+ dev_err(hba->dev,
+ "dme-reset: error code %d\n", ret);
+
+ return ret;
+}
+
+/**
+ * ufshcd_dme_enable - UIC command for DME_ENABLE
+ * @hba: per adapter instance
+ *
+ * DME_ENABLE command is issued in order to enable UniPro stack.
+ *
+ * Returns 0 on success, non-zero value on failure
+ */
+static int ufshcd_dme_enable(struct ufs_hba *hba)
+{
+ struct uic_command uic_cmd = {0};
+ int ret;
+
+ uic_cmd.command = UIC_CMD_DME_ENABLE;
+
+ ret = ufshcd_send_uic_cmd(hba, &uic_cmd);
+ if (ret)
+ dev_err(hba->dev,
+ "dme-reset: error code %d\n", ret);
+
+ return ret;
+}
static inline void ufshcd_add_delay_before_dme_cmd(struct ufs_hba *hba)
{
@@ -2643,7 +2689,7 @@ out:
}
/**
- * ufshcd_hba_enable - initialize the controller
+ * ufshcd_hba_execute_hce - initialize the controller
* @hba: per adapter instance
*
* The controller resets itself and controller firmware initialization
@@ -2652,7 +2698,7 @@ out:
*
* Returns 0 on success, non-zero value on failure
*/
-static int ufshcd_hba_enable(struct ufs_hba *hba)
+static int ufshcd_hba_execute_hce(struct ufs_hba *hba)
{
int retry;
@@ -2718,6 +2764,32 @@ static int ufshcd_hba_enable(struct ufs_hba *hba)
return 0;
}
+static int ufshcd_hba_enable(struct ufs_hba *hba)
+{
+ int ret;
+
+ if (hba->quirks & UFSHCI_QUIRK_BROKEN_HCE) {
+ ufshcd_set_link_off(hba);
+ if (hba->vops && hba->vops->hce_enable_notify)
+ hba->vops->hce_enable_notify(hba, PRE_CHANGE);
+
+ /* enable UIC related interrupts */
+ ufshcd_enable_intr(hba, UFSHCD_UIC_MASK);
+ ret = ufshcd_dme_reset(hba);
+ if (!ret) {
+ ret = ufshcd_dme_enable(hba);
+ if (!ret && hba->vops && hba->vops->hce_enable_notify)
+ hba->vops->hce_enable_notify(hba, POST_CHANGE);
+ if (ret)
+ dev_err(hba->dev,
+ "Host controller enable failed with
non-hce\n");
+ }
+ } else {
+ ret = ufshcd_hba_execute_hce(hba);
+ }
+
+ return ret;
+}
static int ufshcd_disable_tx_lcc(struct ufs_hba *hba, bool peer)
{
int tx_lanes, i, err = 0;
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 0b185e1..a4543c8 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -477,6 +477,11 @@ struct ufs_hba {
*/
#define UFSHCI_QUIRK_SKIP_RESET_INTR_AGGR UFS_BIT(8)
+ /*
+* This quirks needs to be enabled if host controller cannot be
+* enabled via HCE register.
+*/
+ #define UFSHCI_QUIRK_BROKEN_HCE UFS_BIT(9)
unsigned int quirks;/* Deviations from standard UFSHCI spec. */
wait_queue_head_t tm_wq;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 05/13] scsi: ufs: add quirk not to allow reset of interrupt aggregation
From: Seungwon Jeon
Some host controller supports interrupt aggregation, but doesn't
allow to reset counter and timer by s/w.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c |3 ++-
drivers/scsi/ufs/ufshcd.h |6 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index d41d57d..e388edc 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -3205,7 +3205,8 @@ static void ufshcd_transfer_req_compl(struct ufs_hba *hba)
* false interrupt if device completes another request after resetting
* aggregation and before reading the DB.
*/
- if (ufshcd_is_intr_aggr_allowed(hba))
+ if (ufshcd_is_intr_aggr_allowed(hba) &&
+ !(hba->quirks & UFSHCI_QUIRK_SKIP_RESET_INTR_AGGR))
ufshcd_reset_intr_aggr(hba);
tr_doorbell = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 3702b92..0b185e1 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -471,6 +471,12 @@ struct ufs_hba {
*/
#define UFSHCI_QUIRK_BROKEN_REQ_LIST_CLRUFS_BIT(7)
+ /*
+* This quirk needs to be enabled if host controller doesn't allow
+* that the interrupt aggregation timer and counter are reset by s/w.
+*/
+ #define UFSHCI_QUIRK_SKIP_RESET_INTR_AGGR UFS_BIT(8)
+
unsigned int quirks;/* Deviations from standard UFSHCI spec. */
wait_queue_head_t tm_wq;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 07/13] scsi: ufs: add specific callback for nexus type
From: Seungwon Jeon
Some host controller needs nexus type information for handling
command. This change adds specific callback function to support
vendor's implementation.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c |6 ++
drivers/scsi/ufs/ufshcd.h |6 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 07659be..46f92fe 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1378,6 +1378,8 @@ static int ufshcd_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *cmd)
/* issue command to the controller */
spin_lock_irqsave(hba->host->host_lock, flags);
+ if (hba->vops && hba->vops->specify_nexus_t_xfer_req)
+ hba->vops->specify_nexus_t_xfer_req(hba, tag, lrbp->cmd);
ufshcd_send_command(hba, tag);
out_unlock:
spin_unlock_irqrestore(hba->host->host_lock, flags);
@@ -1578,6 +1580,8 @@ static int ufshcd_exec_dev_cmd(struct ufs_hba *hba,
hba->dev_cmd.complete = &wait;
spin_lock_irqsave(hba->host->host_lock, flags);
+ if (hba->vops && hba->vops->specify_nexus_t_xfer_req)
+ hba->vops->specify_nexus_t_xfer_req(hba, tag, lrbp->cmd);
ufshcd_send_command(hba, tag);
spin_unlock_irqrestore(hba->host->host_lock, flags);
@@ -3849,6 +3853,8 @@ static int ufshcd_issue_tm_cmd(struct ufs_hba *hba, int
lun_id, int task_id,
task_req_upiup->input_param2 = cpu_to_be32(task_id);
/* send command to the controller */
+ if (hba->vops && hba->vops->specify_nexus_t_tm_req)
+ hba->vops->specify_nexus_t_tm_req(hba, free_slot, tm_function);
__set_bit(free_slot, &hba->outstanding_tasks);
ufshcd_writel(hba, 1 << free_slot, REG_UTP_TASK_REQ_DOOR_BELL);
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index a4543c8..75af314 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -257,6 +257,9 @@ struct ufs_pwr_mode_info {
* @pwr_change_notify: called before and after a power mode change
* is carried out to allow vendor spesific capabilities
* to be set.
+ * @specify_nexus_t_xfer_req:
+ * @specify_nexus_t_tm_req: called before command is issued to allow vendor
+ * specific handling to be set for nexus type.
* @suspend: called during host controller PM callback
* @resume: called during host controller PM callback
*/
@@ -273,6 +276,9 @@ struct ufs_hba_variant_ops {
int (*pwr_change_notify)(struct ufs_hba *,
bool, struct ufs_pa_layer_attr *,
struct ufs_pa_layer_attr *);
+ void(*specify_nexus_t_xfer_req)(struct ufs_hba *,
+ int, struct scsi_cmnd *);
+ void(*specify_nexus_t_tm_req)(struct ufs_hba *, int, u8);
int (*suspend)(struct ufs_hba *, enum ufs_pm_op);
int (*resume)(struct ufs_hba *, enum ufs_pm_op);
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 09/13] scsi: ufs: make ufshcd_config_pwr_mode of non-static func
From: Seungwon Jeon
This makes ufshcd_config_pwr_mode non-static so that other vendors
like exynos can use the same.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c |5 ++---
drivers/scsi/ufs/ufshcd.h |2 ++
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 73a8d13..66f2fb8 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -185,8 +185,6 @@ static int ufshcd_uic_hibern8_ctrl(struct ufs_hba *hba,
bool en);
static inline void ufshcd_add_delay_before_dme_cmd(struct ufs_hba *hba);
static int ufshcd_host_reset_and_restore(struct ufs_hba *hba);
static irqreturn_t ufshcd_intr(int irq, void *__hba);
-static int ufshcd_config_pwr_mode(struct ufs_hba *hba,
- struct ufs_pa_layer_attr *desired_pwr_mode);
static int ufshcd_change_power_mode(struct ufs_hba *hba,
struct ufs_pa_layer_attr *pwr_mode);
@@ -2598,7 +2596,7 @@ static int ufshcd_change_power_mode(struct ufs_hba *hba,
* @hba: per-adapter instance
* @desired_pwr_mode: desired power configuration
*/
-static int ufshcd_config_pwr_mode(struct ufs_hba *hba,
+int ufshcd_config_pwr_mode(struct ufs_hba *hba,
struct ufs_pa_layer_attr *desired_pwr_mode)
{
struct ufs_pa_layer_attr final_params = { 0 };
@@ -2614,6 +2612,7 @@ static int ufshcd_config_pwr_mode(struct ufs_hba *hba,
return ret;
}
+EXPORT_SYMBOL_GPL(ufshcd_config_pwr_mode);
/**
* ufshcd_complete_dev_init() - checks device readiness
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 845d1c2..f771cb8 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -636,6 +636,8 @@ extern int ufshcd_dme_set_attr(struct ufs_hba *hba, u32
attr_sel,
u8 attr_set, u32 mib_val, u8 peer);
extern int ufshcd_dme_get_attr(struct ufs_hba *hba, u32 attr_sel,
u32 *mib_val, u8 peer);
+extern int ufshcd_config_pwr_mode(struct ufs_hba *hba,
+ struct ufs_pa_layer_attr *desired_pwr_mode);
/* UIC command interfaces for DME primitives */
#define DME_LOCAL 0
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 08/13] scsi: ufs: add add specific callback for hibern8
From: Seungwon Jeon
Some host controller needs specific handling before/after
(un)hibernation, This change adds specific callback function
to support vendor's implementation.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c | 36
drivers/scsi/ufs/ufshcd.h |3 +++
2 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 46f92fe..73a8d13 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -181,8 +181,7 @@ static int ufshcd_probe_hba(struct ufs_hba *hba);
static int __ufshcd_setup_clocks(struct ufs_hba *hba, bool on,
bool skip_ref_clk);
static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on);
-static int ufshcd_uic_hibern8_exit(struct ufs_hba *hba);
-static int ufshcd_uic_hibern8_enter(struct ufs_hba *hba);
+static int ufshcd_uic_hibern8_ctrl(struct ufs_hba *hba, bool en);
static inline void ufshcd_add_delay_before_dme_cmd(struct ufs_hba *hba);
static int ufshcd_host_reset_and_restore(struct ufs_hba *hba);
static irqreturn_t ufshcd_intr(int irq, void *__hba);
@@ -215,6 +214,16 @@ static inline void ufshcd_disable_irq(struct ufs_hba *hba)
}
}
+static inline int ufshcd_uic_hibern8_enter(struct ufs_hba *hba)
+{
+ return ufshcd_uic_hibern8_ctrl(hba, true);
+}
+
+static inline int ufshcd_uic_hibern8_exit(struct ufs_hba *hba)
+{
+ return ufshcd_uic_hibern8_ctrl(hba, false);
+}
+
/*
* ufshcd_wait_for_register - wait for register value to change
* @hba - per-adapter interface
@@ -2396,7 +2405,7 @@ out:
return ret;
}
-static int ufshcd_uic_hibern8_enter(struct ufs_hba *hba)
+static int __ufshcd_uic_hibern8_enter(struct ufs_hba *hba)
{
struct uic_command uic_cmd = {0};
@@ -2405,7 +2414,7 @@ static int ufshcd_uic_hibern8_enter(struct ufs_hba *hba)
return ufshcd_uic_pwr_ctrl(hba, &uic_cmd);
}
-static int ufshcd_uic_hibern8_exit(struct ufs_hba *hba)
+static int __ufshcd_uic_hibern8_exit(struct ufs_hba *hba)
{
struct uic_command uic_cmd = {0};
int ret;
@@ -2420,6 +2429,25 @@ static int ufshcd_uic_hibern8_exit(struct ufs_hba *hba)
return ret;
}
+static int ufshcd_uic_hibern8_ctrl(struct ufs_hba *hba, bool en)
+{
+ int ret;
+
+ if (hba->vops && hba->vops->hibern8_notify)
+ hba->vops->hibern8_notify(hba, en, PRE_CHANGE);
+
+ ret = en ? __ufshcd_uic_hibern8_enter(hba) :
+ __ufshcd_uic_hibern8_exit(hba);
+ if (ret)
+ goto out;
+
+ if (hba->vops && hba->vops->hibern8_notify)
+ hba->vops->hibern8_notify(hba, en, POST_CHANGE);
+
+out:
+ return ret;
+}
+
/**
* ufshcd_init_pwr_info - setting the POR (power on reset)
* values in hba power info
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 75af314..845d1c2 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -260,6 +260,8 @@ struct ufs_pwr_mode_info {
* @specify_nexus_t_xfer_req:
* @specify_nexus_t_tm_req: called before command is issued to allow vendor
* specific handling to be set for nexus type.
+ * @hibern8_notify: called before and after hibernate/unhibernate is carried
out
+ * to allow vendor spesific implementation.
* @suspend: called during host controller PM callback
* @resume: called during host controller PM callback
*/
@@ -276,6 +278,7 @@ struct ufs_hba_variant_ops {
int (*pwr_change_notify)(struct ufs_hba *,
bool, struct ufs_pa_layer_attr *,
struct ufs_pa_layer_attr *);
+ void(*hibern8_notify)(struct ufs_hba *, bool, bool);
void(*specify_nexus_t_xfer_req)(struct ufs_hba *,
int, struct scsi_cmnd *);
void(*specify_nexus_t_tm_req)(struct ufs_hba *, int, u8);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 11/13] Documentation: devicetree: ufs: Add DT bindings for exynos UFS host controller
From: Seungwon Jeon
This adds Exynos Universal Flash Storage (UFS) Host Controller DT bindings.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
.../devicetree/bindings/ufs/ufs-exynos.txt | 93
1 file changed, 93 insertions(+)
create mode 100644 Documentation/devicetree/bindings/ufs/ufs-exynos.txt
diff --git a/Documentation/devicetree/bindings/ufs/ufs-exynos.txt
b/Documentation/devicetree/bindings/ufs/ufs-exynos.txt
new file mode 100644
index 000..00df72e
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/ufs-exynos.txt
@@ -0,0 +1,93 @@
+* Exynos Universal Flash Storage (UFS) Host Controller
+
+UFSHC nodes are defined to describe on-chip UFS host controllers.
+Each UFS controller instance should have its own node.
+
+Required properties:
+- compatible: compatible name, contains "samsung,exynos7-ufs"
+- interrupts:
+- reg :
+
+Optional properties:
+- vdd-hba-supply: phandle to UFS host controller supply regulator node
+- vcc-supply: phandle to VCC supply regulator node
+- vccq-supply : phandle to VCCQ supply regulator node
+- vccq2-supply : phandle to VCCQ2 supply regulator node
+- vcc-supply-1p8: For embedded UFS devices, valid VCC range is
1.7-1.95V
+ or 2.7-3.6V. This boolean property when set,
specifies
+ to use low voltage range of 1.7-1.95V. Note for
external
+ UFS cards this property is invalid and valid VCC
range is
+ always 2.7-3.6V.
+- vcc-max-microamp : specifies max. load that can be drawn from vcc supply
+- vccq-max-microamp : specifies max. load that can be drawn from vccq
supply
+- vccq2-max-microamp: specifies max. load that can be drawn from vccq2
supply
+- -fixed-regulator : boolean property specifying that -supply is a
fixed regulator
+
+- clocks: List of phandle and clock specifier pairs
+- clock-names : List of clock input name strings sorted in the same
+ order as the clocks property.
+- freq-table-hz: Array of operating frequencies
stored in the same
+ order as the clocks property. If this property is not
+ defined or a value in the array is "0" then it is
assumed
+ that the frequency is set by the parent clock or a
+ fixed rate clock source.
+- pclk-freq-avail-range : specifies available frequency range(min/max) for APB
clock
+- ufs,pwr-attr-mode : specifies mode value for power mode change
+- ufs,pwr-attr-lane : specifies lane count value for power mode change
+- ufs,pwr-attr-gear : specifies gear count value for power mode change
+- ufs,pwr-attr-hs-series : specifies HS rate series for power mode change
+- ufs,pwr-local-l2-timer : specifies array of local UNIPRO L2 timer values
+
+- ufs,pwr-remote-l2-timer : specifies array of remote UNIPRO L2 timer values
+
+- ufs-rx-adv-fine-gran-sup_en : specifies support of fine granularity of MPHY,
+ this is a boolean property.
+- ufs-rx-adv-fine-gran-step : specifies granularity steps of MPHY
+- ufs-rx-adv-min-activate-time-cap : specifies rx advanced minimum activate
time of MPHY
+- ufs-pa-granularity : specifies Granularity for PA_TActivate and
PA_Hibern8Time
+- ufs-pa-tacctivate : specifies time wake-up remote M-RX
+- ufs-pa-hibern8time : specifies minimum time to wait in HIBERN8 state
+
+Note: If above properties are not defined it can be assumed that the supply
+regulators or clocks are always on.
+
+Example:
+ ufshc@0x1557 {
+ compatible = "samsung,exynos7-ufs";
+ reg = <0xfc598000 0x800>;
+ reg = <0x1557 0x100>,
+ <0x15570100 0x100>,
+ <0x15571000 0x200>,
+ <0x15572000 0x300>;
+ reg-names = "hci", "vs_hci", "unipro", "ufsp";
+ interrupts = <0 200 0>;
+
+ vdd-hba-supply = <&xxx_reg0>;
+ vdd-hba-fixed-regulator;
+ vcc-supply = <&xxx_reg1>;
+ vcc-supply-1p8;
+ vccq-supply = <&xxx_reg2>;
+ vccq2-supply = <&xxx_reg3>;
+ vcc-max-microamp = 50;
+ vccq-max-microamp = 20;
+ vccq2-max-microamp = 20;
+
+ clocks = <&core 0>, <&ref 0>, <&iface 0>;
+ clock-names = "core_clk", "ref_clk", "iface_clk";
+ freq-table-hz = <1 2>, <0 0>, <0 0>;
+
+ pclk-freq-avail-range = <7000 1330
[PATCH v3 10/13] scsi: ufs: return value of pwr_change_notify
From: Seungwon Jeon
Behavior of the "power mode change" contains vendor specific
operation known as pwr_change_notify. This change adds return
for pwr_change_notify to find success or failure.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 66f2fb8..682abbe 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -2580,14 +2580,18 @@ static int ufshcd_change_power_mode(struct ufs_hba *hba,
dev_err(hba->dev,
"%s: power mode change failed %d\n", __func__, ret);
} else {
- if (hba->vops && hba->vops->pwr_change_notify)
- hba->vops->pwr_change_notify(hba,
- POST_CHANGE, NULL, pwr_mode);
+ if (hba->vops && hba->vops->pwr_change_notify) {
+ ret = hba->vops->pwr_change_notify(hba,
+ POST_CHANGE, NULL, pwr_mode);
+ if (ret)
+ goto out;
+ }
memcpy(&hba->pwr_info, pwr_mode,
sizeof(struct ufs_pa_layer_attr));
}
+out:
return ret;
}
@@ -2602,14 +2606,18 @@ int ufshcd_config_pwr_mode(struct ufs_hba *hba,
struct ufs_pa_layer_attr final_params = { 0 };
int ret;
- if (hba->vops && hba->vops->pwr_change_notify)
- hba->vops->pwr_change_notify(hba,
-PRE_CHANGE, desired_pwr_mode, &final_params);
- else
+ if (hba->vops && hba->vops->pwr_change_notify) {
+ ret = hba->vops->pwr_change_notify(hba,
+ PRE_CHANGE, desired_pwr_mode, &final_params);
+ if (ret)
+ goto out;
+ } else {
memcpy(&final_params, desired_pwr_mode, sizeof(final_params));
+ }
ret = ufshcd_change_power_mode(hba, &final_params);
+out:
return ret;
}
EXPORT_SYMBOL_GPL(ufshcd_config_pwr_mode);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 12/13] scsi: ufs-exynos: add UFS host support for Exynos SoCs
From: Seungwon Jeon
This patch introduces Exynos UFS host controller driver,
which mainly handles vendor-specific operations including
link startup, power mode change and hibernation/unhibernation.
Signed-off-by: Seungwon Jeon
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/Kconfig | 12 +
drivers/scsi/ufs/Makefile|1 +
drivers/scsi/ufs/ufs-exynos-hw.c | 147 +
drivers/scsi/ufs/ufs-exynos-hw.h | 43 ++
drivers/scsi/ufs/ufs-exynos.c| 1186 ++
drivers/scsi/ufs/ufs-exynos.h| 463 +++
drivers/scsi/ufs/ufshci.h| 26 +-
drivers/scsi/ufs/unipro.h| 47 ++
8 files changed, 1924 insertions(+), 1 deletion(-)
create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.c
create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.h
create mode 100644 drivers/scsi/ufs/ufs-exynos.c
create mode 100644 drivers/scsi/ufs/ufs-exynos.h
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index e945383..14544d6 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -83,3 +83,15 @@ config SCSI_UFS_QCOM
Select this if you have UFS controller on QCOM chipset.
If unsure, say N.
+
+config SCSI_UFS_EXYNOS
+ bool "EXYNOS specific hooks to UFS controller platform driver"
+ depends on SCSI_UFSHCD_PLATFORM && ARCH_EXYNOS
+ select PHY_EXYNOS_UFS
+ help
+ This selects the EXYNOS specific additions to UFSHCD platform driver.
+ UFS host on EXYNOS includes HCI and UNIPRO layer, and associates with
+ UFS-PHY driver.
+
+ Select this if you have UFS host controller on EXYNOS chipset.
+ If unsure, say N.
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index 8303bcc..2accf1e 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -1,5 +1,6 @@
# UFSHCD makefile
obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o
+obj-$(CONFIG_SCSI_UFS_EXYNOS) += ufs-exynos.o ufs-exynos-hw.o
obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
diff --git a/drivers/scsi/ufs/ufs-exynos-hw.c b/drivers/scsi/ufs/ufs-exynos-hw.c
new file mode 100644
index 000..3df6d07
--- /dev/null
+++ b/drivers/scsi/ufs/ufs-exynos-hw.c
@@ -0,0 +1,147 @@
+/*
+ * UFS Host Controller driver for Exynos specific extensions
+ *
+ * Copyright (C) 2014-2015 Samsung Electronics Co., Ltd.
+ * Author: Seungwon Jeon
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include "ufshcd.h"
+#include "unipro.h"
+#include "ufs-exynos.h"
+#include "ufs-exynos-hw.h"
+
+static int ufs_clk_set_parent(struct device *dev, const char *c, const char *p)
+{
+ struct clk *_c, *_p;
+
+ _c = devm_clk_get(dev, c);
+ if (IS_ERR(_c)) {
+ dev_err(dev, "failed to get clock %s\n", c);
+ return -EINVAL;
+ }
+
+ _p = devm_clk_get(dev, p);
+ if (IS_ERR(_p)) {
+ dev_err(dev, "failed to get clock %s\n", p);
+ return -EINVAL;
+ }
+
+ return clk_set_parent(_c, _p);
+}
+
+static int exynos7_ufs_drv_init(struct device *dev, struct exynos_ufs *ufs)
+{
+ int ret;
+ const char *const clks[] = {
+ "mout_sclk_combo_phy_embedded",
+ "top_sclk_phy_fsys1_26m",
+ };
+
+ ret = ufs_clk_set_parent(dev, clks[0], clks[1]);
+ if (ret)
+ dev_err(dev, "failed to set parent %s of clock %s\n",
+ clks[1], clks[0]);
+
+ return ret;
+}
+
+static int exynos7_ufs_pre_link(struct exynos_ufs *ufs)
+{
+ struct ufs_hba *hba = ufs->hba;
+ u32 val = ufs->drv_data->uic_attr->pa_dbg_option_suite;
+ int i;
+
+ exynos_ufs_enable_ov_tm(hba);
+ for_each_ufs_tx_lane(ufs, i)
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x297, i), 0x17);
+ for_each_ufs_rx_lane(ufs, i) {
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x362, i), 0xff);
+ ufshcd_dme_set(hba, UIC_ARG_MIB_SEL(0x363, i), 0x00);
+ }
+ exynos_ufs_disable_ov_tm(hba);
+
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_OPTION_SUITE_DYN), 0xf);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_OPTION_SUITE_DYN), 0xf);
+ for_each_ufs_tx_lane(ufs, i)
+ ufshcd_dme_set(hba,
+ UIC_ARG_MIB_SEL(TX_HIBERN8_CONTROL, i), 0x0);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_TXPHY_CFGUPDT), 0x1);
+ udelay(1);
+ ufshcd_dme_set(hba, UIC_ARG_MIB(PA_DBG_OPTION_SUITE), val | (1 << 12));
+ ufshcd_dme_set(hba, UIC_ARG_MIB(P
[PATCH v3 13/13] scsi: ufs: Add exynos ufs platform data
This adds ufs_hba_exynos_ops{} to platform data, so that
exynos ufs driver can be probed.
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd-pltfrm.c |2 ++
drivers/scsi/ufs/ufshcd.h|1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index 7db9564..39dae76 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -373,6 +373,8 @@ static int ufshcd_pltfrm_remove(struct platform_device
*pdev)
static const struct of_device_id ufs_of_match[] = {
{ .compatible = "jedec,ufs-1.1"},
+ { .compatible = "samsung,exynos7-ufs",
+.data = &ufs_hba_exynos_ops},
{},
};
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index f771cb8..776d6e0 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -687,4 +687,5 @@ static inline int ufshcd_dme_peer_get(struct ufs_hba *hba,
int ufshcd_hold(struct ufs_hba *hba, bool async);
void ufshcd_release(struct ufs_hba *hba);
+extern const struct ufs_hba_variant_ops ufs_hba_exynos_ops;
#endif /* End of Header */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 13/13] scsi: ufs: Add exynos ufs platform data
CCing Rob Herring, Hi Arnd, On 10/01/2015 04:59 PM, Arnd Bergmann wrote: On Thursday 01 October 2015 18:46:34 kbuild test robot wrote: [auto build test results on v4.3-rc3 -- if it's inappropriate base, please ignore] config: x86_64-allmodconfig (attached as .config) reproduce: git checkout 6e153e3bf7c68b019e987c5a0ffadebd9c7d4fbb # save the attached .config to linux build tree make ARCH=x86_64 All error/warnings (new ones prefixed by >>): ERROR: "ufs_hba_exynos_ops" [drivers/scsi/ufs/ufshcd-pltfrm.ko] undefined! Ah, this seems to be a case of layering violation. It would be best to restructure the code so that the exynos driver registers a platform_driver by itself for the respective DT compatible string, and then calls into the common code from its probe function, rather than having the generic driver know about the specific backends. That approach will also make the generic driver more scalable as we add further chip-specific variations, and matches what we do in other drivers. Looks like some discussions on ufs variant driver probe method happened here [1] few months back. [1]-> https://lkml.org/lkml/2015/6/3/180 And since ufshcd-pltfrm is already a platform_driver, so I just add a platform data for the variant driver. I should have add a IS_ENABLED for it to avoid the compilation error for other ARCH. Thanks!! Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] scsi: ufs: Add specific callback for setting DMA mask
Currently DMA mask for UFS HCI is set by reading CAP register's
[64AS] bit. Some HCI controller like Exynos support 36-bit bus address.
This works perfectly fine with DMA mask set as 64 in case there is no
IOMMU attached to HCI.
In case if HCI is behind an IOMMU, setting DMA mask as 64 bit won't
work as HCI has only 36bit addressing and SMMU has created mapping of
64 bit and as the device truncates the address, its mapping will not
be found by iommu.
To resolve such issues, let the variant driver sets its own DMA mask.
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c | 3 +++
drivers/scsi/ufs/ufshcd.h | 2 ++
2 files changed, 5 insertions(+)
I am not sure if there are other ways available to handle such cases.
The IOMMU I am talking about is arm-smmu and it DT binding does not
give much idea about handling such cases.
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index a355d98..9a1374e 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -7781,6 +7781,9 @@ EXPORT_SYMBOL_GPL(ufshcd_dealloc_host);
*/
static int ufshcd_set_dma_mask(struct ufs_hba *hba)
{
+ if (hba->vops && hba->vops->set_dam_mask)
+ return bha->vops->set_dma_mask(hba);
+
if (hba->capabilities & MASK_64_ADDRESSING_SUPPORT) {
if (!dma_set_mask_and_coherent(hba->dev, DMA_BIT_MASK(64)))
return 0;
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 1332e54..89c6dae 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -297,6 +297,7 @@ struct ufs_pwr_mode_info {
* @resume: called during host controller PM callback
* @dbg_register_dump: used to dump controller debug information
* @phy_initialization: used to initialize phys
+ * @set_dma_mask: used to set variant specific DMA mask
*/
struct ufs_hba_variant_ops {
const char *name;
@@ -325,6 +326,7 @@ struct ufs_hba_variant_ops {
int (*resume)(struct ufs_hba *, enum ufs_pm_op);
void(*dbg_register_dump)(struct ufs_hba *hba);
int (*phy_initialization)(struct ufs_hba *);
+ int (*set_dma_mask)(struct ufs_hba *hba);
};
/* clock gating state */
--
2.7.4
[RFC PATCH V2] scsi: ufs: Add specific callback for setting DMA mask
Currently DMA mask for UFS HCI is set by reading CAP register's
[64AS] bit. Some HCI controller like Exynos support 36-bit bus address.
This works perfectly fine with DMA mask set as 64 in case there is no
IOMMU attached to HCI.
In case if HCI is behind an IOMMU, setting DMA mask as 64 bit won't
work as HCI has only 36bit addressing and SMMU has created mapping of
64 bit and as the device truncates the address, its mapping will not
be found by iommu.
To resolve such issues, let the variant driver sets its own DMA mask.
Signed-off-by: Alim Akhtar
---
drivers/scsi/ufs/ufshcd.c | 3 +++
drivers/scsi/ufs/ufshcd.h | 2 ++
2 files changed, 5 insertions(+)
I am not sure if there are other ways available to handle such cases.
The IOMMU I am talking about is arm-smmu and it DT binding does not
give much idea about handling such cases.
Have tested this patch with HCI controller with IOMMU attached.
Changes Since V1:
- Fixed build issue as reported by Kbuild test robot.
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index a355d98..9a1374e 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -7781,6 +7781,9 @@ EXPORT_SYMBOL_GPL(ufshcd_dealloc_host);
*/
static int ufshcd_set_dma_mask(struct ufs_hba *hba)
{
+ if (hba->vops && hba->vops->set_dma_mask)
+ return hba->vops->set_dma_mask(hba);
+
if (hba->capabilities & MASK_64_ADDRESSING_SUPPORT) {
if (!dma_set_mask_and_coherent(hba->dev, DMA_BIT_MASK(64)))
return 0;
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 1332e54..89c6dae 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -297,6 +297,7 @@ struct ufs_pwr_mode_info {
* @resume: called during host controller PM callback
* @dbg_register_dump: used to dump controller debug information
* @phy_initialization: used to initialize phys
+ * @set_dma_mask: used to set variant specific DMA mask
*/
struct ufs_hba_variant_ops {
const char *name;
@@ -325,6 +326,7 @@ struct ufs_hba_variant_ops {
int (*resume)(struct ufs_hba *, enum ufs_pm_op);
void(*dbg_register_dump)(struct ufs_hba *hba);
int (*phy_initialization)(struct ufs_hba *);
+ int (*set_dma_mask)(struct ufs_hba *hba);
};
/* clock gating state */
--
2.7.4
Re: [PATCH V3] scsi: ufs: Add specific callback for setting DMA mask
Hi Bart
On 05/20/2018 07:51 PM, Bart Van Assche wrote:
> On Sun, 2018-05-20 at 07:54 +0530, Alim Akhtar wrote:
>> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
>> index a355d98..9a1374e 100644
>> --- a/drivers/scsi/ufs/ufshcd.c
>> +++ b/drivers/scsi/ufs/ufshcd.c
>> @@ -7781,6 +7781,9 @@ EXPORT_SYMBOL_GPL(ufshcd_dealloc_host);
>>*/
>> static int ufshcd_set_dma_mask(struct ufs_hba *hba)
>> {
>> +if (hba->vops && hba->vops->set_dma_mask)
>> +return hba->vops->set_dma_mask(hba);
>> +
>> if (hba->capabilities & MASK_64_ADDRESSING_SUPPORT) {
>> if (!dma_set_mask_and_coherent(hba->dev, DMA_BIT_MASK(64)))
>> return 0;
>> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
>> index 1332e54..89c6dae 100644
>> --- a/drivers/scsi/ufs/ufshcd.h
>> +++ b/drivers/scsi/ufs/ufshcd.h
>> @@ -297,6 +297,7 @@ struct ufs_pwr_mode_info {
>>* @resume: called during host controller PM callback
>>* @dbg_register_dump: used to dump controller debug information
>>* @phy_initialization: used to initialize phys
>> + * @set_dma_mask: used to set variant specific DMA mask
>>*/
>> struct ufs_hba_variant_ops {
>> const char *name;
>> @@ -325,6 +326,7 @@ struct ufs_hba_variant_ops {
>> int (*resume)(struct ufs_hba *, enum ufs_pm_op);
>> void(*dbg_register_dump)(struct ufs_hba *hba);
>> int (*phy_initialization)(struct ufs_hba *);
>> +int (*set_dma_mask)(struct ufs_hba *hba);
>> };
>
> I want to see the code that sets the .set_dma_mask callback function. Where
> is it? If it is outside the upstream kernel, please consider to send it
> upstream before making changes like this. Adding support for out-of-tree
> kernel code is frowned upon big time in the kernel community.
>
Thanks for review and feedback.
Ok, I will include this patch with the series which uses this particular
patch set.
Thanks!
> Bart.
>
>
>
Re: [PATCH] ARM: dts: exynos: Add missing CPU clocks to secondary CPUs on Exynos542x
Hi Krzysztof, On Wed, May 30, 2018 at 10:19 PM, Krzysztof Kozlowski wrote: > Secondary CPUs should have the same information in DeviceTree as booting > CPU from both correctness point of view and for possible hotplug > scenarios. > > Suggested-by: Viresh Kumar > Signed-off-by: Krzysztof Kozlowski > --- > arch/arm/boot/dts/exynos5420-cpus.dtsi | 6 ++ > arch/arm/boot/dts/exynos5422-cpus.dtsi | 8 +++- > 2 files changed, 13 insertions(+), 1 deletion(-) Reviewed-by: Alim Akhtar Tested on exynos5800 peach-pi, so feel free to add Tested-by: Alim Akhtar > > diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi > b/arch/arm/boot/dts/exynos5420-cpus.dtsi > index a8e449471304..0ee6e92a3c29 100644 > --- a/arch/arm/boot/dts/exynos5420-cpus.dtsi > +++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi > @@ -38,6 +38,7 @@ > device_type = "cpu"; > compatible = "arm,cortex-a15"; > reg = <0x1>; > + clocks = <&clock CLK_ARM_CLK>; > clock-frequency = <18>; > cci-control-port = <&cci_control1>; > operating-points-v2 = <&cluster_a15_opp_table>; > @@ -49,6 +50,7 @@ > device_type = "cpu"; > compatible = "arm,cortex-a15"; > reg = <0x2>; > + clocks = <&clock CLK_ARM_CLK>; > clock-frequency = <18>; > cci-control-port = <&cci_control1>; > operating-points-v2 = <&cluster_a15_opp_table>; > @@ -60,6 +62,7 @@ > device_type = "cpu"; > compatible = "arm,cortex-a15"; > reg = <0x3>; > + clocks = <&clock CLK_ARM_CLK>; > clock-frequency = <18>; > cci-control-port = <&cci_control1>; > operating-points-v2 = <&cluster_a15_opp_table>; > @@ -83,6 +86,7 @@ > device_type = "cpu"; > compatible = "arm,cortex-a7"; > reg = <0x101>; > + clocks = <&clock CLK_KFC_CLK>; > clock-frequency = <10>; > cci-control-port = <&cci_control0>; > operating-points-v2 = <&cluster_a7_opp_table>; > @@ -94,6 +98,7 @@ > device_type = "cpu"; > compatible = "arm,cortex-a7"; > reg = <0x102>; > + clocks = <&clock CLK_KFC_CLK>; > clock-frequency = <10>; > cci-control-port = <&cci_control0>; > operating-points-v2 = <&cluster_a7_opp_table>; > @@ -105,6 +110,7 @@ > device_type = "cpu"; > compatible = "arm,cortex-a7"; > reg = <0x103>; > + clocks = <&clock CLK_KFC_CLK>; > clock-frequency = <10>; > cci-control-port = <&cci_control0>; > operating-points-v2 = <&cluster_a7_opp_table>; > diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi > b/arch/arm/boot/dts/exynos5422-cpus.dtsi > index 7c130a00d1a8..e4a5857c135f 100644 > --- a/arch/arm/boot/dts/exynos5422-cpus.dtsi > +++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi > @@ -37,6 +37,7 @@ > device_type = "cpu"; > compatible = "arm,cortex-a7"; > reg = <0x101>; > + clocks = <&clock CLK_KFC_CLK>; > clock-frequency = <10>; > cci-control-port = <&cci_control0>; > operating-points-v2 = <&cluster_a7_opp_table>; > @@ -48,6 +49,7 @@ > device_type = "cpu"; > compatible = "arm,cortex-a7"; > reg = <0x102>; > + clocks = <&clock CLK_KFC_CLK>; > clock-frequency = <10>; > cci-c
Re: [PATCH] mmc: dw_mmc: Don't send clock off command if power is off
Hi Doug, On Fri, Mar 20, 2015 at 11:30 PM, Doug Anderson wrote: > We've already seen that it causes failures if we try to send the > "SDMMC_CMD_UPD_CLK" command when power is off to the system. Here's > another case where we were doing it: we were sending an > SDMMC_CMD_UPD_CLK to set the clock to 0 when the card was already > powered off and the clock was already at 0. Let's avoid that command > and avoid problems. > > Signed-off-by: Doug Anderson > --- > drivers/mmc/host/dw_mmc.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c > index 47dfd0e..aeec698 100644 > --- a/drivers/mmc/host/dw_mmc.c > +++ b/drivers/mmc/host/dw_mmc.c > @@ -1172,8 +1172,9 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct > mmc_ios *ios) > > break; > case MMC_POWER_OFF: > - /* Turn clock off before power goes down */ > - dw_mci_setup_bus(slot, false); > + /* Turn clock off before power goes down; only if powered */ > + if (slot->host->vqmmc_enabled) > + dw_mci_setup_bus(slot, false); > vqmmc_enabled is always _true_ when entering MMC_POWER_OFF case..right? Is this done for extra protection? Or do you have a case where vqmmc is OFF and driver still calls dw_mci_setup_bus from here? > if (!IS_ERR(mmc->supply.vmmc)) > mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0); > -- > 2.2.0.rc0.207.ga3a616c > > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Alim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Add required changes to ufshcd to support exynos ufs hci
Hi All, Any thought on this patch set? On Sun, May 6, 2018 at 3:44 PM, Alim Akhtar wrote: > Hi All > > These patches are part of a larger patch series [1] which attempts upstreaming > EXYNOS UFS driver support. There was not much activities after v5 of that > series. In between I saw there were other teams in Samsung tried upstreaming > the same, but that has not really gone anywhere. > I have taken this task again and here is another attempt to upstream > exynos-ufs > driver support. I have divided the patches into two series, one which adds > required infra in the ufshcd core needed by exynos-ufs driver and other part > will have actual exynos-ufs driver. Splitting this has a advantage of less > reviewing over head. > > I am floating these as a new patch set. > > [1] https://www.spinics.net/lists/linux-scsi/msg90292.html > > These patches are based on mainline v4.17-rc3. > > Alim Akhtar (4): > scsi: ufs: add quirk to fix mishandling utrlclr/utmrlclr > scsi: ufs: add quirk not to allow reset of interrupt aggregation > scsi: ufs: add quirk to enable host controller without hce > scsi: ufs: make ufshcd_config_pwr_mode of non-static func > > drivers/scsi/ufs/ufshcd.c | 104 > ++ > drivers/scsi/ufs/ufshcd.h | 18 > 2 files changed, 114 insertions(+), 8 deletions(-) > > -- > 2.7.4 > -- Regards, Alim
Re: [RFC PATCH V2] scsi: ufs: Add specific callback for setting DMA mask
Ping !!!
On Thu, Mar 8, 2018 at 4:33 PM, Alim Akhtar wrote:
> Currently DMA mask for UFS HCI is set by reading CAP register's
> [64AS] bit. Some HCI controller like Exynos support 36-bit bus address.
> This works perfectly fine with DMA mask set as 64 in case there is no
> IOMMU attached to HCI.
> In case if HCI is behind an IOMMU, setting DMA mask as 64 bit won't
> work as HCI has only 36bit addressing and SMMU has created mapping of
> 64 bit and as the device truncates the address, its mapping will not
> be found by iommu.
> To resolve such issues, let the variant driver sets its own DMA mask.
>
> Signed-off-by: Alim Akhtar
> ---
> drivers/scsi/ufs/ufshcd.c | 3 +++
> drivers/scsi/ufs/ufshcd.h | 2 ++
> 2 files changed, 5 insertions(+)
>
> I am not sure if there are other ways available to handle such cases.
> The IOMMU I am talking about is arm-smmu and it DT binding does not
> give much idea about handling such cases.
> Have tested this patch with HCI controller with IOMMU attached.
>
> Changes Since V1:
> - Fixed build issue as reported by Kbuild test robot.
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index a355d98..9a1374e 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -7781,6 +7781,9 @@ EXPORT_SYMBOL_GPL(ufshcd_dealloc_host);
> */
> static int ufshcd_set_dma_mask(struct ufs_hba *hba)
> {
> + if (hba->vops && hba->vops->set_dma_mask)
> + return hba->vops->set_dma_mask(hba);
> +
> if (hba->capabilities & MASK_64_ADDRESSING_SUPPORT) {
> if (!dma_set_mask_and_coherent(hba->dev, DMA_BIT_MASK(64)))
> return 0;
> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> index 1332e54..89c6dae 100644
> --- a/drivers/scsi/ufs/ufshcd.h
> +++ b/drivers/scsi/ufs/ufshcd.h
> @@ -297,6 +297,7 @@ struct ufs_pwr_mode_info {
> * @resume: called during host controller PM callback
> * @dbg_register_dump: used to dump controller debug information
> * @phy_initialization: used to initialize phys
> + * @set_dma_mask: used to set variant specific DMA mask
> */
> struct ufs_hba_variant_ops {
> const char *name;
> @@ -325,6 +326,7 @@ struct ufs_hba_variant_ops {
> int (*resume)(struct ufs_hba *, enum ufs_pm_op);
> void(*dbg_register_dump)(struct ufs_hba *hba);
> int (*phy_initialization)(struct ufs_hba *);
> + int (*set_dma_mask)(struct ufs_hba *hba);
> };
>
> /* clock gating state */
> --
> 2.7.4
>
--
Regards,
Alim
Re: [PATCH v3 5/5] Revert "scsi: ufs: disable vccq if it's not needed by UFS device"
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: Marc Gonzalez
> ---
AFAIK Samsung and Toshiba UFS devices does not use VCCQ (this pin is
either floating or connected to Ground, at least on the devices that I
have worked on).
You said your system hanged, I believe you have set UFS_DEVICE_NO_VCCQ
quirks, in that case VCCQ regulator should having been disabled.
So you mean your system hanged because vccq regulator got disabled?
> drivers/scsi/ufs/ufs.h| 1 -
> drivers/scsi/ufs/ufshcd.c | 59 +++
> 2 files changed, 4 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
> index dd65fea07687..7da7318eb6a6 100644
> --- a/drivers/scsi/ufs/ufs.h
> +++ b/drivers/scsi/ufs/ufs.h
> @@ -514,7 +514,6 @@ struct ufs_vreg {
> struct regulator *reg;
> const char *name;
> bool enabled;
> - bool unused;
> int min_uV;
> int max_uV;
> int min_uA;
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 9ba7671b84f8..8b9a01073d62 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -245,7 +245,6 @@ static int ufshcd_probe_hba(struct ufs_hba *hba);
> static int __ufshcd_setup_clocks(struct ufs_hba *hba, bool on,
>bool skip_ref_clk);
> static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on);
> -static int ufshcd_set_vccq_rail_unused(struct ufs_hba *hba, bool unused);
> static int ufshcd_uic_hibern8_exit(struct ufs_hba *hba);
> static int ufshcd_uic_hibern8_enter(struct ufs_hba *hba);
> static inline void ufshcd_add_delay_before_dme_cmd(struct ufs_hba *hba);
> @@ -6819,11 +6818,6 @@ static int ufshcd_probe_hba(struct ufs_hba *hba)
> ufs_fixup_device_setup(hba, &card);
> ufshcd_tune_unipro_params(hba);
>
> - ret = ufshcd_set_vccq_rail_unused(hba,
> - (hba->dev_quirks & UFS_DEVICE_NO_VCCQ) ? true : false);
> - if (ret)
> - goto out;
> -
> /* UFS device is also active now */
> ufshcd_set_ufs_dev_active(hba);
> ufshcd_force_reset_auto_bkops(hba);
> @@ -7007,24 +7001,13 @@ static int ufshcd_config_vreg_load(struct device
> *dev, struct ufs_vreg *vreg,
> static inline int ufshcd_config_vreg_lpm(struct ufs_hba *hba,
>struct ufs_vreg *vreg)
> {
> - if (!vreg)
> - return 0;
> - else if (vreg->unused)
> - return 0;
> - else
> - return ufshcd_config_vreg_load(hba->dev, vreg,
> -UFS_VREG_LPM_LOAD_UA);
> + return ufshcd_config_vreg_load(hba->dev, vreg, UFS_VREG_LPM_LOAD_UA);
> }
>
> static inline int ufshcd_config_vreg_hpm(struct ufs_hba *hba,
>struct ufs_vreg *vreg)
> {
> - if (!vreg)
> - return 0;
> - else if (vreg->unused)
> - return 0;
> - else
> - return ufshcd_config_vreg_load(hba->dev, vreg, vreg->max_uA);
> + return ufshcd_config_vreg_load(hba->dev, vreg, vreg->max_uA);
> }
>
> static int ufshcd_config_vreg(struct device *dev,
> @@ -7062,9 +7045,7 @@ static int ufshcd_enable_vreg(struct device *dev,
> struct ufs_vreg *vreg)
> {
> int ret = 0;
>
> - if (!vreg)
> - goto out;
> - else if (vreg->enabled || vreg->unused)
> + if (!vreg || vreg->enabled)
> goto out;
>
> ret = ufshcd_config_vreg(dev, vreg, true);
> @@ -7084,9 +7065,7 @@ static int ufshcd_disable_vreg(struct device *dev,
> struct ufs_vreg *vreg)
> {
> int ret = 0;
>
> - if (!vreg)
> - goto out;
> - else if (!vreg->enabled || vreg->unused)
> + if (!vreg || !vreg->enabled)
> goto out;
>
> ret = regulator_disable(vreg->reg);
> @@ -7192,36 +7171,6 @@ static int ufshcd_init_hba_vreg(struct ufs_hba *hba)
> return 0;
> }
>
> -static int ufshcd_set_vccq_rail_unused(struct ufs_hba *hba, bool unused)
> -{
> - int ret = 0;
> - struct ufs_vreg_info *info = &hba->vreg_info;
> -
> - if (!info)
> - goto out;
> - else if (!info->vccq)
> - goto out;
> -
> - if (unused) {
> - /* shut off the rail here */
> - ret = ufshcd_toggle_vreg(hba->dev, info->vccq, false);
> - /*
> - * Mark this rail as no longer used, so it doesn't get enabled
> - * later by mistake
> - */
> - if (!ret)
> - info->vccq->unused = true;
> - } else {
> - /*
> - * rail should have been already enabled hence just make sure
> - * that unused flag is cleared.
> - */
> - info->vc
Re: [PATCH v3 5/5] Revert "scsi: ufs: disable vccq if it's not needed by UFS device"
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, 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: Marc Gonzalez
>>> ---
>>
>> AFAIK Samsung and Toshiba UFS devices does not use VCCQ (this pin is
>> either floating or connected to Ground, at least on the devices that I
>> have worked on).
>
> But why does such system define a vccq-supply? If the system doesn't
> have a regulator connected to VCCQ, then the UFS driver shouldn't be
> told that there is one. And if VCCQ is optional the UFS driver should
> support the fact that this regulator might not be supplied (i.e. call
> regulator_get_optional() and handle the error indicating that the supply
> isn't specified).
>
As per JESD220C, chapter 6.1, it does says "VCCQ - Supply voltage used
typically for the memory controller and optionally for the PHY
interface, the memory IO, and any other internal very low voltage block"
And we have VCCQ2 - which serve the pretty much same purpose. The
voltage range for VCCQ and VCCQ2 are different, VCCQ has a lower voltage
suitable to some low voltage block inside UFS device. I think this is
design consideration which allow some vendor to use one less physical
pin may be. And also depends on the voltage requirements of some of the
internal circuit.
> Regards,
> Bjorn
>
>> You said your system hanged, I believe you have set UFS_DEVICE_NO_VCCQ
>> quirks, in that case VCCQ regulator should having been disabled.
>> So you mean your system hanged because vccq regulator got disabled?
>>
>>>drivers/scsi/ufs/ufs.h| 1 -
>>>drivers/scsi/ufs/ufshcd.c | 59 +++
>>>2 files changed, 4 insertions(+), 56 deletions(-)
>>>
>>> diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
>>> index dd65fea07687..7da7318eb6a6 100644
>>> --- a/drivers/scsi/ufs/ufs.h
>>> +++ b/drivers/scsi/ufs/ufs.h
>>> @@ -514,7 +514,6 @@ struct ufs_vreg {
>>> struct regulator *reg;
>>> const char *name;
>>> bool enabled;
>>> - bool unused;
>>> int min_uV;
>>> int max_uV;
>>> int min_uA;
>>> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
>>> index 9ba7671b84f8..8b9a01073d62 100644
>>> --- a/drivers/scsi/ufs/ufshcd.c
>>> +++ b/drivers/scsi/ufs/ufshcd.c
>>> @@ -245,7 +245,6 @@ static int ufshcd_probe_hba(struct ufs_hba *hba);
>>>static int __ufshcd_setup_clocks(struct ufs_hba *hba, bool on,
>>> bool skip_ref_clk);
>>>static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on);
>>> -static int ufshcd_set_vccq_rail_unused(struct ufs_hba *hba, bool unused);
>>>static int ufshcd_uic_hibern8_exit(struct ufs_hba *hba);
>>>static int ufshcd_uic_hibern8_enter(struct ufs_hba *hba);
>>>static inline void ufshcd_add_delay_before_dme_cmd(struct ufs_hba *hba);
>>> @@ -6819,11 +6818,6 @@ static int ufshcd_probe_hba(struct ufs_hba *hba)
>>> ufs_fixup_device_setup(hba, &card);
>>> ufshcd_tune_unipro_params(hba);
>>>
>>> - ret = ufshcd_set_vccq_rail_unused(hba,
>>> - (hba->dev_quirks & UFS_DEVICE_NO_VCCQ) ? true : false);
>>> - if (ret)
>>> - goto out;
>>> -
>>> /* UFS device is also active now */
>>> ufshcd_set_ufs_dev_active(hba);
>>> ufshcd_force_reset_auto_bkops(hba);
>>> @@ -7007,24 +7001,13 @@ static int ufshcd_config_vreg_load(struct device
>>> *dev, struct ufs_vreg *vreg,
>>>static inline int ufshcd_config_vreg_lpm(struct ufs_hba *hba,
>>> struct ufs_vreg *vreg)
>>>{
>>> - if (!vreg)
>>> - return 0;
>>> - else if (vreg->unused)
>>> - return 0;
>>> - else
>>> - return ufshcd_config_vreg_load(hba->dev, vreg,
>>> - UFS_VREG_LPM_LOAD_UA);
>>> + return ufshcd_config_vreg_load(hba->dev, vreg, UFS_VREG_LPM_LOAD_UA);
>>>}
>>>
>>>static inline int ufshcd_config_vreg_hpm(struct ufs_hba *hba,
>>> struct ufs_vreg *vreg)
>>>
Re: [PATCH v3 5/5] Revert "scsi: ufs: disable vccq if it's not needed by UFS device"
On 06/02/19 1:16 AM, Bjorn Andersson wrote:
> 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, 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: Marc Gonzalez
>>>>> ---
>>>>
>>>> AFAIK Samsung and Toshiba UFS devices does not use VCCQ (this pin is
>>>> either floating or connected to Ground, at least on the devices that I
>>>> have worked on).
>>>
>>> But why does such system define a vccq-supply? If the system doesn't
>>> have a regulator connected to VCCQ, then the UFS driver shouldn't be
>>> told that there is one. And if VCCQ is optional the UFS driver should
>>> support the fact that this regulator might not be supplied (i.e. call
>>> regulator_get_optional() and handle the error indicating that the supply
>>> isn't specified).
>>>
>> As per JESD220C, chapter 6.1, it does says "VCCQ - Supply voltage used
>> typically for the memory controller and optionally for the PHY
>> interface, the memory IO, and any other internal very low voltage block"
>> And we have VCCQ2 - which serve the pretty much same purpose. The
>> voltage range for VCCQ and VCCQ2 are different, VCCQ has a lower voltage
>> suitable to some low voltage block inside UFS device. I think this is
>> design consideration which allow some vendor to use one less physical
>> pin may be. And also depends on the voltage requirements of some of the
>> internal circuit.
>>
>
> This looks to me that you are required to have a VCCQ. But you said that
> you do not have a regulator supplying VCCQ on your board, and if that
> really is the case then you should not specify vccq-supply.
>
> The patch Marc is reverting states that for devices that does not have
> VCCQ connected, some unrelated regulator should be assigned to the UFS
> driver so that it can turn it off.
>
>
> If you have a regulator connected to VCCQ then it should go in
> vccq-supply, if you have a regulator connected to VCCQ2 the is should go
> in vccq2-supply. If you don't have these pins connected then there
> shouldn't be any regulators specified here!
>
Yes, that's correct, it should be like what you are suggesting, DT
entries should match the board schematic.
> Regards,
> Bjorn
>
>>
>>> Regards,
>>> Bjorn
>>>
>>>> You said your system hanged, I believe you have set UFS_DEVICE_NO_VCCQ
>>>> quirks, in that case VCCQ regulator should having been disabled.
>>>> So you mean your system hanged because vccq regulator got disabled?
>>>>
>>>>> drivers/scsi/ufs/ufs.h| 1 -
>>>>> drivers/scsi/ufs/ufshcd.c | 59 +++
>>>>> 2 files changed, 4 insertions(+), 56 deletions(-)
>>>>>
>>>>> diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
>>>>> index dd65fea07687..7da7318eb6a6 100644
>>>>> --- a/drivers/scsi/ufs/ufs.h
>>>>> +++ b/drivers/scsi/ufs/ufs.h
>>>>> @@ -514,7 +514,6 @@ struct ufs_vreg {
>>>>> struct regulator *reg;
>>>>> const char *name;
>>>>> bool enabled;
>>>>> - bool unused;
>>>>> int min_uV;
>>>>> int max_uV;
>>>>> int min_uA;
>>>>> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
>>>>> index 9ba7671b84f8..8b9a01073d62 100644
>>>>> --- a/drivers/scsi/ufs/ufshcd.c
>>>>> +++ b/drivers/scsi/ufs/ufshcd.c
>>>>> @@ -245,7 +245,6 @@ static int ufshcd_probe_hba(struct ufs_hba *hba);
>>>>> static int __ufshcd_setup_clocks(struct ufs_hba *hba, bool on,
>>>>>bool skip_ref_clk);
>>>>> static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on);
>>>>> -static int ufshcd_set_vccq_rail_unused(struct ufs_hba *hba, bool unused);
>>>>> static int ufshcd_uic_hibern8_exit(struct ufs_hba *hba);
>>>>> static int ufshcd_uic_hibern8_enter(struct ufs_
Re: [PATCH v3 5/5] Revert "scsi: ufs: disable vccq if it's not needed by UFS device"
Hi Marc, On 06/02/19 8:29 PM, Marc Gonzalez wrote: > [ 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 cherry-pick the appropriate fix, the board >> no longer reboots, but UFS init does fail. >> >> Full boot log here: >> https://pastebin.ubuntu.com/p/KwpRnWMFw5/ > > Here's a better failure log, with timestamps: > > [0.00] Booting Linux on physical CPU 0x00 [0x51af8014] > [0.00] Linux version 5.0.0-rc5-next-20190206 (mgonzalez@venus) (gcc > version 7.3.1 20180425 [linaro-7.3-2018.05 revision > d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05)) #19 SMP > PREEMPT Wed Feb 6 15:42:45 CET 2019 > [0.00] Machine model: Qualcomm Technologies, Inc. MSM8998 v1 MTP > [0.00] printk: debug: ignoring loglevel setting. > [0.00] On node 0 totalpages: 1028544 > [0.00] DMA32 zone: 8192 pages used for memmap > [0.00] DMA32 zone: 0 pages reserved > [0.00] DMA32 zone: 511488 pages, LIFO batch:63 > [0.00] Normal zone: 8079 pages used for memmap > [0.00] Normal zone: 517056 pages, LIFO batch:63 > [0.00] psci: probing for conduit method from DT. > [0.00] psci: PSCIv1.0 detected in firmware. > [0.00] psci: Using standard PSCI v0.2 function IDs > [0.00] psci: MIGRATE_INFO_TYPE not supported. > [0.00] psci: SMC Calling Convention v1.0 > [0.00] random: get_random_bytes called from start_kernel+0xa8/0x470 > with crng_init=0 > [0.00] percpu: Embedded 22 pages/cpu @(ptrval) s50184 r8192 > d31736 u90112 > [0.00] pcpu-alloc: s50184 r8192 d31736 u90112 alloc=22*4096 > [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 > [0.00] Detected VIPT I-cache on CPU0 > [0.00] CPU features: detected: Kernel page table isolation (KPTI) > [0.00] Built 1 zonelists, mobility grouping on. Total pages: 1012273 > [0.00] Kernel command line: ignore_loglevel > androidboot.bootdevice=1da4000.ufshc androidboot.serialno=53733c35 > androidboot.baseband=apq mdss_mdp.panel=1:hdmi:16 > [0.00] Dentry cache hash table entries: 524288 (order: 10, 4194304 > bytes) > [0.00] Inode-cache hash table entries: 262144 (order: 9, 2097152 > bytes) > [0.00] software IO TLB: mapped [mem 0xfbfff000-0xf000] (64MB) > [0.00] Memory: 3955464K/4114176K available (3262K kernel code, 410K > rwdata, 944K rodata, 6016K init, 1161K bss, 158712K reserved, 0K cma-reserved) > [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 > [0.00] ftrace: allocating 12605 entries in 50 pages > [0.00] rcu: Preemptible hierarchical RCU implementation. > [0.00] rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=8. > [0.00] Tasks RCU enabled. > [0.00] rcu: RCU calculated value of scheduler-enlistment delay is 25 > jiffies. > [0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8 > [0.00] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 > [0.00] REMAP: PA=17a0 VA=ff801004 SIZE=1 > [0.00] REMAP: PA=17b0 VA=ff8010d0 SIZE=10 > [0.00] GICv3: Distributor has no Range Selector support > [0.00] GICv3: no VLPI support, no direct LPI support > [0.00] GICv3: CPU0: found redistributor 0 region 0:0x17b0 > [0.00] ITS: No ITS available, not enabling LPIs > [0.00] REMAP: PA=1792 VA=ff8010005000 SIZE=1000 > [0.00] REMAP: PA=17921000 VA=ff801000d000 SIZE=1000 > [0.00] REMAP: PA=17921000 VA=ff8010015000 SIZE=1000 > [0.00] arch_timer: cp15 and mmio timer(s) running at 19.20MHz > (virt/virt). > [0.00] clocksource: arch_sys_counter: mask: 0xff > max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns > [0.03] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every > 4398046511078ns > [0.61] Console: colour dummy device 80x25 > [0.000405] printk: console [tty0] enabled > [0.000428] Calibrating delay loop (skipped), value calculated using timer > frequency.. 38.40 BogoMIPS (lpj=76800) > [0.000444] pid_max: default: 32768 minimum: 301 > [0.000542] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes) > [0.000563] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 > bytes) > [0.000864] *** VALIDATE proc *** > [0.023878] ASID allocator initialised with 32768 entries > [0.031878] rcu: Hierarchical SRCU implementation. > [0.051914] smp: Bringing up secondary CPUs ... > [0.086062] Detected VIPT I-cache on CPU1 > [0.086092] GICv3: CPU1: found redistributor 1 region 0:0x17b2
Re: [PATCH v3 5/5] Revert "scsi: ufs: disable vccq if it's not needed by UFS device"
Hi Marc, On 06/02/19 9:22 PM, Marc Gonzalez wrote: > 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.930447] ufshcd-qcom 1da4000.ufshc: ufshcd_query_attr: opcode 0x04 >>> for idn 13 failed, index 0, err = -11 >>> [5.434358] ufshcd-qcom 1da4000.ufshc: ufshcd_query_attr: opcode 0x04 >>> for idn 13 failed, index 0, err = -11 >>> [6.938318] ufshcd-qcom 1da4000.ufshc: ufshcd_query_attr: opcode 0x04 >>> for idn 13 failed, index 0, err = -11 >>> [6.938414] ufshcd-qcom 1da4000.ufshc: ufshcd_query_attr_retry: query >>> attribute, idn 13, failed with error -11 after 3 retires >>> [6.946959] ufshcd-qcom 1da4000.ufshc: ufshcd_disable_auto_bkops: failed >>> to enable exception event -11 >>> [6.958523] ufshcd-qcom 1da4000.ufshc: dme-peer-get: attr-id 0x1587 >>> failed 3 retries >>> [6.967730] ufshcd-qcom 1da4000.ufshc: dme-peer-get: attr-id 0x1586 >>> failed 3 retries >>> [6.975576] ufshcd-qcom 1da4000.ufshc: ufshcd_get_max_pwr_mode: invalid >>> max pwm tx gear read = 0 >>> [6.983306] ufshcd-qcom 1da4000.ufshc: ufshcd_probe_hba: Failed getting >>> max supported power mode >>> [8.506314] ufshcd-qcom 1da4000.ufshc: ufshcd_query_flag: Sending flag >>> query for idn 3 failed, err = -11 >>> [ 10.010352] ufshcd-qcom 1da4000.ufshc: ufshcd_query_flag: Sending flag >>> query for idn 3 failed, err = -11 >>> [ 11.514313] ufshcd-qcom 1da4000.ufshc: ufshcd_query_flag: Sending flag >>> query for idn 3 failed, err = -11 >>> [ 11.514412] ufshcd-qcom 1da4000.ufshc: ufshcd_query_flag_retry: query >>> attribute, opcode 5, idn 3, failed with error -11 after 3 retires >>> [ 13.050354] ufshcd-qcom 1da4000.ufshc: __ufshcd_query_descriptor: opcode >>> 0x01 for idn 8 failed, index 0, err = -11 >>> [ 14.554313] ufshcd-qcom 1da4000.ufshc: __ufshcd_query_descriptor: opcode >>> 0x01 for idn 8 failed, index 0, err = -11 >>> [ 16.058313] ufshcd-qcom 1da4000.ufshc: __ufshcd_query_descriptor: opcode >>> 0x01 for idn 8 failed, index 0, err = -11 >>> [ 16.058421] ufshcd-qcom 1da4000.ufshc: ufshcd_read_desc_param: Failed >>> reading descriptor. desc_id 8, desc_index 0, param_offset 0, ret -11 >>> [ 16.067654] ufshcd-qcom 1da4000.ufshc: ufshcd_init_icc_levels: Failed >>> reading power descriptor.len = 98 ret = -11 >>> [ 37.074334] ufshcd-qcom 1da4000.ufshc: link startup failed 1 >> >> Can you check if your UFS device RESET_N is asserted correctly. It might >> be connected to some regulator and may be you can try keeping that >> regulator as "regulator-always-on" from your DT node. > > How do I check RESET_N? In software or hardware? > RST_N is the reset logic for UFS device core logic and it is input to the device from UFS host controller.So, in your platform please check if this line somehow connected to (pulled up) a PMIC supply. If that is the case, please keep that regulator ON and see if this issue is resolved. > Do you think it is not a good idea to revert > 60f0187031c05e04cbadffb62f557d0ff3564490 ? > Please hold on till we understand the real cause of this issue. Or we have a consensuses for reverting the said commit. Thanks! > Regards. > >
RE: [PATCH v10 10/10] arm64: dts: Add node for ufs exynos7
> -Original Message- > From: Krzysztof Kozlowski > Sent: 29 May 2020 13:36 > To: Alim Akhtar > Cc: r...@kernel.org; devicet...@vger.kernel.org; linux-s...@vger.kernel.org; > avri.alt...@wdc.com; martin.peter...@oracle.com; > kwmad@samsung.com; stanley@mediatek.com; > c...@codeaurora.org; linux-samsung-...@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v10 10/10] arm64: dts: Add node for ufs exynos7 > > On Thu, May 28, 2020 at 06:46:58AM +0530, Alim Akhtar wrote: > > Adding dt node foe UFS and UFS-PHY for exynos7 SoC. > > > > Signed-off-by: Alim Akhtar > > Tested-by: Paweł Chmiel > > --- > > .../boot/dts/exynos/exynos7-espresso.dts | 4 ++ > > arch/arm64/boot/dts/exynos/exynos7.dtsi | 43 ++- > > Thanks, applied to next/dt-late. It might miss this merge window and in such > case I will keep it for v5.9 cycle. Thanks Krzysztof. > > Best regards, > Krzysztof
RE: [PATCH v10 00/10] exynos-ufs: Add support for UFS HCI
> -Original Message- > From: Alim Akhtar > Sent: 28 May 2020 06:47 > To: r...@kernel.org > Cc: devicet...@vger.kernel.org; linux-s...@vger.kernel.org; k...@kernel.org; > avri.alt...@wdc.com; martin.peter...@oracle.com; > kwmad@samsung.com; stanley@mediatek.com; > c...@codeaurora.org; linux-samsung-...@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Alim Akhtar > > Subject: [PATCH v10 00/10] exynos-ufs: Add support for UFS HCI > > This patch-set introduces UFS (Universal Flash Storage) host controller > support > for Samsung family SoC. Mostly, it consists of UFS PHY and host specific > driver. > . . . > Alim Akhtar (9): > scsi: ufs: add quirk to fix mishandling utrlclr/utmrlclr > scsi: ufs: add quirk to disallow reset of interrupt aggregation > scsi: ufs: add quirk to enable host controller without hce > scsi: ufs: introduce UFSHCD_QUIRK_PRDT_BYTE_GRAN quirk > dt-bindings: phy: Document Samsung UFS PHY bindings > phy: samsung-ufs: add UFS PHY driver for samsung SoC > dt-bindings: ufs: Add bindings for Samsung ufs host > scsi: ufs-exynos: add UFS host support for Exynos SoCs > arm64: dts: Add node for ufs exynos7 > > Kiwoong Kim (1): > scsi: ufs: add quirk to fix abnormal ocs fatal error > > .../bindings/phy/samsung,ufs-phy.yaml | 75 + > .../bindings/ufs/samsung,exynos-ufs.yaml | 89 ++ > .../boot/dts/exynos/exynos7-espresso.dts |4 + > arch/arm64/boot/dts/exynos/exynos7.dtsi | 43 +- > drivers/phy/samsung/Kconfig |9 + > drivers/phy/samsung/Makefile |1 + > drivers/phy/samsung/phy-exynos7-ufs.h | 86 ++ > drivers/phy/samsung/phy-samsung-ufs.c | 380 + > drivers/phy/samsung/phy-samsung-ufs.h | 143 ++ > drivers/scsi/ufs/Kconfig | 12 + > drivers/scsi/ufs/Makefile |1 + > drivers/scsi/ufs/ufs-exynos.c | 1292 + > drivers/scsi/ufs/ufs-exynos.h | 287 > drivers/scsi/ufs/ufshcd.c | 126 +- > drivers/scsi/ufs/ufshcd.h | 29 + > drivers/scsi/ufs/unipro.h | 33 + > 16 files changed, 2596 insertions(+), 14 deletions(-) > create mode 100644 Documentation/devicetree/bindings/phy/samsung,ufs- > phy.yaml > create mode 100644 Documentation/devicetree/bindings/ufs/samsung,exynos- > ufs.yaml > create mode 100644 drivers/phy/samsung/phy-exynos7-ufs.h > create mode 100644 drivers/phy/samsung/phy-samsung-ufs.c > create mode 100644 drivers/phy/samsung/phy-samsung-ufs.h > create mode 100644 drivers/scsi/ufs/ufs-exynos.c > create mode 100644 drivers/scsi/ufs/ufs-exynos.h > Hi Martin and Kishon, Can you please take the patches into your respective trees? Thanks, > > base-commit: 0e698dfa282211e414076f9dc7e83c1c288314fd > -- > 2.17.1
RE: [PATCH v9 10/10] arm64: dts: Add node for ufs exynos7
> -Original Message- > From: Krzysztof Kozlowski > Sent: 19 May 2020 12:47 > To: Alim Akhtar > Cc: r...@kernel.org; devicet...@vger.kernel.org; linux-s...@vger.kernel.org; > avri.alt...@wdc.com; martin.peter...@oracle.com; > kwmad@samsung.com; stanley@mediatek.com; > c...@codeaurora.org; linux-samsung-...@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v9 10/10] arm64: dts: Add node for ufs exynos7 > > On Thu, May 14, 2020 at 06:09:14AM +0530, Alim Akhtar wrote: > > Adding dt node foe UFS and UFS-PHY for exynos7 SoC. > > > > Signed-off-by: Alim Akhtar > > Tested-by: Paweł Chmiel > > --- > > .../boot/dts/exynos/exynos7-espresso.dts | 4 ++ > > arch/arm64/boot/dts/exynos/exynos7.dtsi | 43 ++- > > 2 files changed, 45 insertions(+), 2 deletions(-) > > I will pick it up after all bindings get Rob's ack (or are picked up as > well). The > second bindings patch are still pending on that. > Thank Krzysztof, Yes, one binding still awaiting Rob's ack, I have addressed his comment in this v9 series. Hoping he will find some time to review the same. > Best regards, > Krzysztof
RE: [RESEND PATCH v10 04/10] scsi: ufs: introduce UFSHCD_QUIRK_PRDT_BYTE_GRAN quirk
Hi Eric,
> -Original Message-
> From: Eric Biggers
> Sent: 12 August 2020 05:59
> To: Alim Akhtar
> Cc: r...@kernel.org; devicet...@vger.kernel.org;
linux-s...@vger.kernel.org;
> k...@kernel.org; avri.alt...@wdc.com; martin.peter...@oracle.com;
> kwmad@samsung.com; stanley@mediatek.com;
> c...@codeaurora.org; linux-samsung-...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; kis...@ti.com
> Subject: Re: [RESEND PATCH v10 04/10] scsi: ufs: introduce
> UFSHCD_QUIRK_PRDT_BYTE_GRAN quirk
>
> Hi Alim,
>
> On Sat, Jun 13, 2020 at 08:17:00AM +0530, Alim Akhtar wrote:
> > Some UFS host controllers like Exynos uses granularities of PRDT
> > length and offset as bytes, whereas others uses actual segment count.
> >
> > Reviewed-by: Avri Altman
> > Signed-off-by: Kiwoong Kim
> > Signed-off-by: Alim Akhtar
> > ---
> > drivers/scsi/ufs/ufshcd.c | 30 +++---
> > drivers/scsi/ufs/ufshcd.h | 6 ++
> > 2 files changed, 29 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> > index ee30ed6cc805..ba093d0d0942 100644
> > --- a/drivers/scsi/ufs/ufshcd.c
> > +++ b/drivers/scsi/ufs/ufshcd.c
> > @@ -2151,8 +2151,14 @@ static int ufshcd_map_sg(struct ufs_hba *hba,
> struct ufshcd_lrb *lrbp)
> > return sg_segments;
> >
> > if (sg_segments) {
> > - lrbp->utr_descriptor_ptr->prd_table_length =
> > - cpu_to_le16((u16)sg_segments);
> > +
> > + if (hba->quirks & UFSHCD_QUIRK_PRDT_BYTE_GRAN)
> > + lrbp->utr_descriptor_ptr->prd_table_length =
> > + cpu_to_le16((sg_segments *
> > + sizeof(struct ufshcd_sg_entry)));
> > + else
> > + lrbp->utr_descriptor_ptr->prd_table_length =
> > + cpu_to_le16((u16) (sg_segments));
> >
> > prd_table = (struct ufshcd_sg_entry *)lrbp->ucd_prdt_ptr;
> >
> > @@ -3500,11 +3506,21 @@ static void
> ufshcd_host_memory_configure(struct ufs_hba *hba)
> >
> cpu_to_le32(upper_32_bits(cmd_desc_element_addr));
> >
> > /* Response upiu and prdt offset should be in double words
*/
> > - utrdlp[i].response_upiu_offset =
> > - cpu_to_le16(response_offset >> 2);
> > - utrdlp[i].prd_table_offset = cpu_to_le16(prdt_offset >> 2);
> > - utrdlp[i].response_upiu_length =
> > - cpu_to_le16(ALIGNED_UPIU_SIZE >> 2);
> > + if (hba->quirks & UFSHCD_QUIRK_PRDT_BYTE_GRAN) {
> > + utrdlp[i].response_upiu_offset =
> > + cpu_to_le16(response_offset);
> > + utrdlp[i].prd_table_offset =
> > + cpu_to_le16(prdt_offset);
> > + utrdlp[i].response_upiu_length =
> > + cpu_to_le16(ALIGNED_UPIU_SIZE);
> > + } else {
> > + utrdlp[i].response_upiu_offset =
> > + cpu_to_le16(response_offset >> 2);
> > + utrdlp[i].prd_table_offset =
> > + cpu_to_le16(prdt_offset >> 2);
> > + utrdlp[i].response_upiu_length =
> > + cpu_to_le16(ALIGNED_UPIU_SIZE >> 2);
> > + }
> >
> > ufshcd_init_lrb(hba, &hba->lrb[i], i);
> > }
>
> Isn't this patch missing an update to ufshcd_print_trs()? It uses
> ->prd_table_length as the number of segments, not the number of bytes.
>
prd_table_length will be populated before it reaches ufshcd_print_trs()
based on UFSHCD_QUIRK_PRDT_BYTE_GRAN.
> - Eric
RE: [PATCH v8 0/4] scsi: ufs: Add Host Performance Booster Support
> -Original Message- > From: Avri Altman > Sent: 06 August 2020 19:27 > To: Bean Huo ; daejun7.p...@samsung.com; > j...@linux.ibm.com; martin.peter...@oracle.com; asuto...@codeaurora.org; > bean...@micron.com; stanley@mediatek.com; c...@codeaurora.org; > bvanass...@acm.org; tomas.wink...@intel.com; ALIM AKHTAR > > Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org; Sang-yoon Oh > ; Sung-Jun Park > ; yongmyung lee > ; Jinyoung CHOI ; > Adel Choi ; BoRam Shin > > Subject: RE: [PATCH v8 0/4] scsi: ufs: Add Host Performance Booster Support > > > > > > On Thu, 2020-08-06 at 10:12 +, Avri Altman wrote: > > > > > > > > > > > > > we didn't see you Acked-by in the pathwork, would you like to add > > > > them? > > > > Just for reminding us that you have agreed to mainline this series > > > > patchset. > > > > > > I acked it - > > > https://protect2.fireeye.com/url?k=039c5a1c-5e48e674-039dd153-0cc47a > > > 3356b2- > 66867eb5b9700b6a&q=1&u=https%3A%2F%2Fwww.spinics.net%2Flists% > > > 2Flinux-scsi%2Fmsg144660.html > > > And asked Martin to move forward - > > > https://protect2.fireeye.com/url?k=94dceb38-c9085750-94dd6077-0cc47a > > > 3356b2- > 19ab1f41f48ff179&q=1&u=https%3A%2F%2Fwww.spinics.net%2Flists% > > > 2Flinux-scsi%2Fmsg144738.html Which he did, and got some sparse > > > errors: > > > https://protect2.fireeye.com/url?k=a40e2dd1-f9da91b9-a40fa69e-0cc47a > > > 3356b2- > 81fae05297aebb0e&q=1&u=https%3A%2F%2Fwww.spinics.net%2Flists% > > > 2Flinux-scsi%2Fmsg144977.html > > > Which I asked Daejun to fix - > > > https://protect2.fireeye.com/url?k=6badf100-36794d68-6bac7a4f-0cc47a > > > 3356b2- > f84580e236611583&q=1&u=https%3A%2F%2Fwww.spinics.net%2Flists% > > > 2Flinux-scsi%2Fmsg144987.html > > > > > > For the next chain of events I guess you can follow by yourself. > > > > > > Thanks, > > > Avri > > > > Avri > > Sorry for making you confusing. yes, I knew that, and following. > > I mean Acked-by tag in the patchset, then we see your acked in the > > patchwork, and let others know that you acked it, rather than going > > backtrack history email. > > > > Hi Daejun > > I think you can add Avri's Acked-by tag in your patchset, just for > > quickly moving forward and reminding. > Ahhh - One moment please - > While rebasing the v8 on my platform, I noticed some substantial changes since > v6. > e.g. the hpb lun ref counting isn't there anymore, as well as some more stuff. > While those changes might be only for the best, I think any tested-by tag > should > be re-assign. > > Anyway, as for myself, I am not planning to put any more time in this, until > there > is a clear decision where this series is going to. > > Martin - Are you considering to merge the HPB feature eventually to mainline > kernel? > V8 has removed the "UFS feature layer" which was the main topic of discussion. What else we thing is blocking this to be in mainline? Bart / Martin, any thought? > Thanks, > Avri > > > > thanks, > > Bean
RE: [RFT PATCH v5] serial: samsung: Removes the IRQ not found warning
Hi Tamseel,
> -Original Message-
> From: Tamseel Shams
> Sent: 10 August 2020 08:30
> To: kg...@kernel.org; k...@kernel.org; gre...@linuxfoundation.org;
> jsl...@suse.com
> Cc: linux-arm-ker...@lists.infradead.org; linux-samsung-...@vger.kernel.org;
> linux-ser...@vger.kernel.org; linux-kernel@vger.kernel.org;
> alim.akh...@samsung.com; Tamseel Shams
> Subject: [RFT PATCH v5] serial: samsung: Removes the IRQ not found warning
>
> In few older Samsung SoCs like s3c2410, s3c2412 and s3c2440, UART IP is having
> 2 interrupt lines.
> However, in other SoCs like s3c6400, s5pv210, exynos5433, and exynos4210
> UART is having only 1 interrupt line. Due to this, "platform_get_irq(platdev,
> 1)"
> call in the driver gives the following false-positive error:
> "IRQ index 1 not found" on newer SoC's.
>
> This patch adds the condition to check for Tx interrupt only for the those
> SoC's
> which have 2 interrupt lines.
>
> Signed-off-by: Tamseel Shams
> ---
Tested on exynos7 platform, don’t see " IRQ index 1 not found" with this patch
applied
Fill free to added
Tested-by: Alim Akhtar
Reviewed-by: Alim Akhtar
> Commit message is changed.
>
> Added RFT, for older platform.
>
> Addressed Krzysztof's review comments [1] [1] ->
> https://lkml.org/lkml/2020/7/21/150
>
> drivers/tty/serial/samsung_tty.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/tty/serial/samsung_tty.c
> b/drivers/tty/serial/samsung_tty.c
> index 6ef614d8648c..b923683e6a25 100644
> --- a/drivers/tty/serial/samsung_tty.c
> +++ b/drivers/tty/serial/samsung_tty.c
> @@ -1911,9 +1911,11 @@ static int s3c24xx_serial_init_port(struct
> s3c24xx_uart_port *ourport,
> ourport->tx_irq = ret + 1;
> }
>
> - ret = platform_get_irq(platdev, 1);
> - if (ret > 0)
> - ourport->tx_irq = ret;
> + if (!s3c24xx_serial_has_interrupt_mask(port)) {
> + ret = platform_get_irq(platdev, 1);
> + if (ret > 0)
> + ourport->tx_irq = ret;
> + }
> /*
>* DMA is currently supported only on DT platforms, if DMA properties
>* are specified.
> --
> 2.17.1
RE: [PATCH 0/2] two UFS changes
Hi Bean, > -Original Message- > From: Bean Huo > Sent: 08 December 2020 00:32 > To: alim.akh...@samsung.com; avri.alt...@wdc.com; > asuto...@codeaurora.org; j...@linux.ibm.com; > martin.peter...@oracle.com; stanley@mediatek.com; > bean...@micron.com; bvanass...@acm.org; tomas.wink...@intel.com; > c...@codeaurora.org > Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: [PATCH 0/2] two UFS changes > > From: Bean Huo > > > > Bean Huo (2): > scsi: ufs: Remove an unused macro definition POWER_DESC_MAX_SIZE > scsi: ufs: Fix wrong print message in dev_err() > > drivers/scsi/ufs/ufs.h| 1 - > drivers/scsi/ufs/ufshcd.c | 2 +- > 2 files changed, 1 insertion(+), 2 deletions(-) > Thanks! Acked-by: Alim Akhtar > -- > 2.17.1
Re: [PATCH] iio: adc: exynos: drop unneeded variable assignment
On Sat, Apr 10, 2021 at 10:18 PM Krzysztof Kozlowski wrote: > > The initialization of 'ret' variable in probe function is shortly after > overwritten. This initialization is simply not used. > > Addresses-Coverity: Unused value > Signed-off-by: Krzysztof Kozlowski > --- Thanks Krzysztof, Reviewed-by: Alim Akhtar > drivers/iio/adc/exynos_adc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c > index 784c10deeb1a..2d8e36408f0e 100644 > --- a/drivers/iio/adc/exynos_adc.c > +++ b/drivers/iio/adc/exynos_adc.c > @@ -794,7 +794,7 @@ static int exynos_adc_probe(struct platform_device *pdev) > struct s3c2410_ts_mach_info *pdata = dev_get_platdata(&pdev->dev); > struct iio_dev *indio_dev = NULL; > bool has_ts = false; > - int ret = -ENODEV; > + int ret; > int irq; > > indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(struct > exynos_adc)); > -- > 2.25.1 > -- Regards, Alim
RE: [PATCH -next] scsi: ufs: fix all Kconfig help text indentation
Hello Randy, > -Original Message- > From: Randy Dunlap > Sent: 07 January 2021 02:26 > To: linux-kernel@vger.kernel.org > Cc: Randy Dunlap ; Alim Akhtar > ; Avri Altman ; linux- > s...@vger.kernel.org; James E.J. Bottomley ; Martin K. > Petersen > Subject: [PATCH -next] scsi: ufs: fix all Kconfig help text indentation > > Use consistent and expected indentation for all Kconfig text. > > Signed-off-by: Randy Dunlap > Cc: Alim Akhtar > Cc: Avri Altman > Cc: linux-s...@vger.kernel.org > Cc: "James E.J. Bottomley" > Cc: "Martin K. Petersen" > --- Reviewed-by: Alim Akhtar
Re: [PATCH] mmc: dw_mmc: Don't print data errors
Hi Doug, On Wed, Apr 23, 2014 at 5:21 AM, Doug Anderson wrote: > Data errors are completely expected during tuning. Printing them out > is confusing people looking at the kernel logs. They see things like: > > [3.613296] dwmmc_exynos 1220.dwmmc0: data error, status 0x0088 > > ...and they think something is wrong with their hardware. > > Remove the printouts. We'll leave it up to a higher level to report > about errors. > > Signed-off-by: Doug Anderson This looks reasonable Reviewed-by: Alim Akhtar > --- > drivers/mmc/host/dw_mmc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c > index cced599..4c8d423 100644 > --- a/drivers/mmc/host/dw_mmc.c > +++ b/drivers/mmc/host/dw_mmc.c > @@ -1248,7 +1248,7 @@ static int dw_mci_data_complete(struct dw_mci *host, > struct mmc_data *data) > data->error = -EIO; > } > > - dev_err(host->dev, "data error, status 0x%08x\n", status); > + dev_dbg(host->dev, "data error, status 0x%08x\n", status); > > /* > * After an error, there may be data lingering > -- > 1.9.1.423.g4596e3a > > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Alim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tty/serial: samsung: Add earlycon support
Just realized that linux-arm-kernel email-id was wrongly typed.
CCing the correct linux-arm-kernel email-id now.
Sorry for the noise.
On Tue, Sep 16, 2014 at 5:02 PM, Alim Akhtar wrote:
> Add earlycon support for the samsung serial port. This allows enabling
> the samsung serial port for console when early_params are parse and processed.
>
> Signed-off-by: Alim Akhtar
> ---
> Documentation/kernel-parameters.txt |6 ++
> drivers/tty/serial/Kconfig |1 +
> drivers/tty/serial/samsung.c| 17 +
> 3 files changed, 24 insertions(+)
>
> diff --git a/Documentation/kernel-parameters.txt
> b/Documentation/kernel-parameters.txt
> index 5ae8608..e01c0e5 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -936,6 +936,12 @@ bytes respectively. Such letter suffixes can also be
> entirely omitted.
> must already be setup and configured. Options are not
> yet supported.
>
> + samsung,
> + Start an early, polled-mode console on a samsung
> serial
> + port at the specified address. The samsung serial port
> + must already be setup and configured. Options are not
> + yet supported.
> +
> smh Use ARM semihosting calls for early console.
>
> earlyprintk=[X86,SH,BLACKFIN,ARM,M68k]
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 249e340..9d42ac8 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -257,6 +257,7 @@ config SERIAL_SAMSUNG_CONSOLE
> bool "Support for console on Samsung SoC serial port"
> depends on SERIAL_SAMSUNG=y
> select SERIAL_CORE_CONSOLE
> + select SERIAL_EARLYCON
> help
> Allow selection of the S3C24XX on-board serial ports for use as
> an virtual console.
> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
> index c78f43a..f32e9c8 100644
> --- a/drivers/tty/serial/samsung.c
> +++ b/drivers/tty/serial/samsung.c
> @@ -917,6 +917,7 @@ s3c24xx_serial_verify_port(struct uart_port *port, struct
> serial_struct *ser)
> #ifdef CONFIG_SERIAL_SAMSUNG_CONSOLE
>
> static struct console s3c24xx_serial_console;
> +static void s3c24xx_serial_console_putchar(struct uart_port *port, int ch);
>
> static int __init s3c24xx_serial_console_init(void)
> {
> @@ -926,6 +927,22 @@ static int __init s3c24xx_serial_console_init(void)
> console_initcall(s3c24xx_serial_console_init);
>
> #define S3C24XX_SERIAL_CONSOLE &s3c24xx_serial_console
> +static void samsung_early_write(struct console *con, const char *s, unsigned
> n)
> +{
> + struct earlycon_device *dev = con->data;
> +
> + uart_console_write(&dev->port, s, n, s3c24xx_serial_console_putchar);
> +}
> +
> +static int __init samsung_early_console_setup(struct earlycon_device *device,
> + const char *opt)
> +{
> + if (!device->port.membase)
> + return -ENODEV;
> + device->con->write = samsung_early_write;
> + return 0;
> +}
> +EARLYCON_DECLARE(samsung, samsung_early_console_setup);
> #else
> #define S3C24XX_SERIAL_CONSOLE NULL
> #endif
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Regards,
Alim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tty/serial: samsung: Add earlycon support
Hi Tomasz,
Thanks for your valuable feedback on this patch.
Please see my comments inline.
On Sat, Sep 20, 2014 at 7:09 PM, Tomasz Figa wrote:
> Hi Alim,
>
> Please see my comments inline.
>
> On 16.09.2014 13:32, Alim Akhtar wrote:
>> Add earlycon support for the samsung serial port. This allows enabling
>> the samsung serial port for console when early_params are parse and
>> processed.
>>
>> Signed-off-by: Alim Akhtar
>> ---
>> Documentation/kernel-parameters.txt |6 ++
>> drivers/tty/serial/Kconfig |1 +
>> drivers/tty/serial/samsung.c| 17 +
>> 3 files changed, 24 insertions(+)
>>
>> diff --git a/Documentation/kernel-parameters.txt
>> b/Documentation/kernel-parameters.txt
>> index 5ae8608..e01c0e5 100644
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -936,6 +936,12 @@ bytes respectively. Such letter suffixes can also be
>> entirely omitted.
>> must already be setup and configured. Options are not
>> yet supported.
>>
>> + samsung,
>> + Start an early, polled-mode console on a samsung serial
>> + port at the specified address. The samsung serial port
>> + must already be setup and configured. Options are not
>> + yet supported.
>> +
>
> Couldn't you simply parse this from DT? I believe there is already code
> parsing stdout property in chosen node for earlycon purposes present in
> the kernel.
>
> Anyway, we already had a patch for this in our internal tree, but it
> wasn't submitted because there was no support for early ioremap on ARM
> at that time. I haven't been following it since then (and I'm no longer
> at Samsung; Marek might be able to take this topic), is it already
> available?
I am not sure what you have internally, any further suggestions on
this is most welcome.
As you said there is no support for ioremap on ARM, so this is not
tested on ARM.
>
>> smh Use ARM semihosting calls for early console.
>>
>> earlyprintk=[X86,SH,BLACKFIN,ARM,M68k]
>> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
>> index 249e340..9d42ac8 100644
>> --- a/drivers/tty/serial/Kconfig
>> +++ b/drivers/tty/serial/Kconfig
>> @@ -257,6 +257,7 @@ config SERIAL_SAMSUNG_CONSOLE
>> bool "Support for console on Samsung SoC serial port"
>> depends on SERIAL_SAMSUNG=y
>> select SERIAL_CORE_CONSOLE
>> + select SERIAL_EARLYCON
>> help
>> Allow selection of the S3C24XX on-board serial ports for use as
>> an virtual console.
>> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
>> index c78f43a..f32e9c8 100644
>> --- a/drivers/tty/serial/samsung.c
>> +++ b/drivers/tty/serial/samsung.c
>> @@ -917,6 +917,7 @@ s3c24xx_serial_verify_port(struct uart_port *port,
>> struct serial_struct *ser)
>> #ifdef CONFIG_SERIAL_SAMSUNG_CONSOLE
>>
>> static struct console s3c24xx_serial_console;
>> +static void s3c24xx_serial_console_putchar(struct uart_port *port, int ch);
>>
>> static int __init s3c24xx_serial_console_init(void)
>> {
>> @@ -926,6 +927,22 @@ static int __init s3c24xx_serial_console_init(void)
>> console_initcall(s3c24xx_serial_console_init);
>>
>> #define S3C24XX_SERIAL_CONSOLE &s3c24xx_serial_console
>> +static void samsung_early_write(struct console *con, const char *s,
>> unsigned n)
>> +{
>> + struct earlycon_device *dev = con->data;
>> +
>> + uart_console_write(&dev->port, s, n, s3c24xx_serial_console_putchar);
>
> Hmm, I'm not sure how this is supposed to work before the driver is
> fully initialized.
>
> s3c24xx_serial_console_putchar() will call
> s3c24xx_serial_console_txrdy(), which in turn requires the port argument
> to be a pointer to the member of a s3c24xx_uart_port struct, with filled
> info pointer, which I believe is ready only after s3c24xx_serial_probe().
>
I see your point here, but I did not hit any error or any runtime
crash with this patch when test on ARM64. In order to keep my changes
minimal I tried to reused the code already there in this file and that
worked for me. The reason why this is working is, if you see
s3c24xx_serial_console_txdy(), _info_ pointer is used in a conditional
operator and not really involved in any manipulation.
I am not sure if compiler should have give some warnings or error here.
But certainly this is not t
Re: [PATCH] tty/serial: samsung: Add earlycon support
Hi Tomasz,
On Sun, Sep 21, 2014 at 10:54 PM, Tomasz Figa wrote:
> On 21.09.2014 16:36, Alim Akhtar wrote:
>> Hi Tomasz,
>> Thanks for your valuable feedback on this patch.
>
> You're welcome.
>
>>>> diff --git a/Documentation/kernel-parameters.txt
>>>> b/Documentation/kernel-parameters.txt
>>>> index 5ae8608..e01c0e5 100644
>>>> --- a/Documentation/kernel-parameters.txt
>>>> +++ b/Documentation/kernel-parameters.txt
>>>> @@ -936,6 +936,12 @@ bytes respectively. Such letter suffixes can also be
>>>> entirely omitted.
>>>> must already be setup and configured. Options are not
>>>> yet supported.
>>>>
>>>> + samsung,
>>>> + Start an early, polled-mode console on a samsung
>>>> serial
>>>> + port at the specified address. The samsung serial
>>>> port
>>>> + must already be setup and configured. Options are not
>>>> + yet supported.
>>>> +
>>>
>>> Couldn't you simply parse this from DT? I believe there is already code
>>> parsing stdout property in chosen node for earlycon purposes present in
>>> the kernel.
>>>
>>> Anyway, we already had a patch for this in our internal tree, but it
>>> wasn't submitted because there was no support for early ioremap on ARM
>>> at that time. I haven't been following it since then (and I'm no longer
>>> at Samsung; Marek might be able to take this topic), is it already
>>> available?
>> I am not sure what you have internally, any further suggestions on
>> this is most welcome.
>
> I believe Marek should be able to post our internal patch, so maybe you
> could reuse it and adapt for your needs.
>
>> As you said there is no support for ioremap on ARM, so this is not
>> tested on ARM.
>
> Don't forget that this driver is primarily targeted for ARM platforms
> (versus just one ARM64-based Exynos7), so either this feature should be
> clearly added as ARM64-specific (and compiled in conditionally) or made
> work for all supported platforms.
>
Well, this will work on every platform which uses
"samsung,exynos4210-uart" as a UART controller.
Exynos7 also use same, there is nothing special about ARM64 bit here.
please see[1].
For "s3c24xx-uart", this has to be implemented separably as that is a
bit different.
>>>
>>>> smh Use ARM semihosting calls for early console.
>>>>
>>>> earlyprintk=[X86,SH,BLACKFIN,ARM,M68k]
>>>> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
>>>> index 249e340..9d42ac8 100644
>>>> --- a/drivers/tty/serial/Kconfig
>>>> +++ b/drivers/tty/serial/Kconfig
>>>> @@ -257,6 +257,7 @@ config SERIAL_SAMSUNG_CONSOLE
>>>> bool "Support for console on Samsung SoC serial port"
>>>> depends on SERIAL_SAMSUNG=y
>>>> select SERIAL_CORE_CONSOLE
>>>> + select SERIAL_EARLYCON
>>>> help
>>>> Allow selection of the S3C24XX on-board serial ports for use as
>>>> an virtual console.
>>>> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
>>>> index c78f43a..f32e9c8 100644
>>>> --- a/drivers/tty/serial/samsung.c
>>>> +++ b/drivers/tty/serial/samsung.c
>>>> @@ -917,6 +917,7 @@ s3c24xx_serial_verify_port(struct uart_port *port,
>>>> struct serial_struct *ser)
>>>> #ifdef CONFIG_SERIAL_SAMSUNG_CONSOLE
>>>>
>>>> static struct console s3c24xx_serial_console;
>>>> +static void s3c24xx_serial_console_putchar(struct uart_port *port, int
>>>> ch);
>>>>
>>>> static int __init s3c24xx_serial_console_init(void)
>>>> {
>>>> @@ -926,6 +927,22 @@ static int __init s3c24xx_serial_console_init(void)
>>>> console_initcall(s3c24xx_serial_console_init);
>>>>
>>>> #define S3C24XX_SERIAL_CONSOLE &s3c24xx_serial_console
>>>> +static void samsung_early_write(struct console *con, const char *s,
>>>> unsigned n)
>>>> +{
>>>> + struct earlycon_device *dev = con->data;
>>>> +
>>>> + uart_console_write(&dev->port, s, n, s3c24xx_serial_console_putchar);
>>>
>>> Hmm, I'm not sure how this is supposed to wo
Re: [PATCH] tty/serial: samsung: Add earlycon support
Hi Tomasz,
On Mon, Sep 22, 2014 at 4:49 AM, Tomasz Figa wrote:
> On 22.09.2014 01:10, Alim Akhtar wrote:
>
> [snip]
>
>>>> As you said there is no support for ioremap on ARM, so this is not
>>>> tested on ARM.
>>>
>>> Don't forget that this driver is primarily targeted for ARM platforms
>>> (versus just one ARM64-based Exynos7), so either this feature should be
>>> clearly added as ARM64-specific (and compiled in conditionally) or made
>>> work for all supported platforms.
>>>
>> Well, this will work on every platform which uses
>> "samsung,exynos4210-uart" as a UART controller.
>> Exynos7 also use same, there is nothing special about ARM64 bit here.
>> please see[1].
>> For "s3c24xx-uart", this has to be implemented separably as that is a
>> bit different.
>
> For this feature, they differ only in locations and lengths of
> FIFO-related bit fields. We had this already implemented for all
> hardware variants and so my recommendation to reuse that code.
>
>>>>>
>>>>>> smh Use ARM semihosting calls for early console.
>>>>>>
>>>>>> earlyprintk=[X86,SH,BLACKFIN,ARM,M68k]
>
> [snip]
>
>> Tomasz/Marek,
>> Do you think something like below make sense here?
>>
>> +static void exynos4210_serial_console_putc(struct uart_port *port, int ch)
>> +{
>> + while (!(readl(port->membase + S3C2410_UFCON) &
>> S3C2410_UFCON_FIFOMODE))
>> + ;
>
> Waiting in a loop for a software-writable FIFO mode enable bit doesn't
> look reasonable to me. Probably a typo?
>
>> +
>> + wr_regb(port, S3C2410_UTXH, ch);
>> +
>> + while ((readl(port->membase + S3C2410_UFSTAT) &
>> S5PV210_UFSTAT_TXFULL))
>> + ;
>
> I wonder if you need to wait for the character to be sent. If you ensure
> before writing a character that there is no previous one in the buffer
> or there is space in FIFO then I believe you should be fine.
>
Well, below is what I was about to post:
#define S3C24XX_SERIAL_CONSOLE &s3c24xx_serial_console
+static void s3c24xx_serial_console_putc(struct uart_port *port, int ch)
+{
+ unsigned int ufcon = rd_regl(port, S3C2410_UFCON);
+
+ if (ufcon & S3C2410_UFCON_FIFOMODE) {
+ while((readl(port->membase + S3C2410_UFSTAT) &
+ S5PV210_UFSTAT_TXFULL))
+ ;
+ wr_regb(port, S3C2410_UTXH, ch);
+ }
+}
+
+static void samsung_early_write(struct console *con, const char *s, unsigned n)
+{
+ struct earlycon_device *dev = con->data;
+
+ uart_console_write(&dev->port, s, n, s3c24xx_serial_console_putc);
+}
+
+static int __init samsung_early_console_setup(struct earlycon_device *device,
+ const char *opt)
+{
+ if (!device->port.membase)
+ return -ENODEV;
+ device->con->write = samsung_early_write;
+ return 0;
+}
+EARLYCON_DECLARE(samsung, samsung_early_console_setup);
+OF_EARLYCON_DECLARE(samsung, "samsung,exynos4210-uart",
samsung_early_console_setup);
but just saw patches from Marek few min back which is similar except
for the handle non-fifo mode, which is good anyway. :-)
So lets drops this patch and discussion here.
Thanks!!!
>> +}
>>
>> and call exynos4210_serial_console_putc() in samsung_early_write()?
>> Anyway functions names need to be changes accordingly.
>
> Yes, this is exactly what we had implemented in the patch I mentioned,
> except that the putc function was generic for all hardware variants.
>
> Best regards,
> Tomasz
--
Regards,
Alim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tty/serial: samsung: Add earlycon support
Add earlycon support for the samsung serial port. This allows enabling
the samsung serial port for console when early_params are parse and processed.
Signed-off-by: Alim Akhtar
---
Documentation/kernel-parameters.txt |6 ++
drivers/tty/serial/Kconfig |1 +
drivers/tty/serial/samsung.c| 17 +
3 files changed, 24 insertions(+)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 5ae8608..e01c0e5 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -936,6 +936,12 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
must already be setup and configured. Options are not
yet supported.
+ samsung,
+ Start an early, polled-mode console on a samsung serial
+ port at the specified address. The samsung serial port
+ must already be setup and configured. Options are not
+ yet supported.
+
smh Use ARM semihosting calls for early console.
earlyprintk=[X86,SH,BLACKFIN,ARM,M68k]
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 249e340..9d42ac8 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -257,6 +257,7 @@ config SERIAL_SAMSUNG_CONSOLE
bool "Support for console on Samsung SoC serial port"
depends on SERIAL_SAMSUNG=y
select SERIAL_CORE_CONSOLE
+ select SERIAL_EARLYCON
help
Allow selection of the S3C24XX on-board serial ports for use as
an virtual console.
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index c78f43a..f32e9c8 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -917,6 +917,7 @@ s3c24xx_serial_verify_port(struct uart_port *port, struct
serial_struct *ser)
#ifdef CONFIG_SERIAL_SAMSUNG_CONSOLE
static struct console s3c24xx_serial_console;
+static void s3c24xx_serial_console_putchar(struct uart_port *port, int ch);
static int __init s3c24xx_serial_console_init(void)
{
@@ -926,6 +927,22 @@ static int __init s3c24xx_serial_console_init(void)
console_initcall(s3c24xx_serial_console_init);
#define S3C24XX_SERIAL_CONSOLE &s3c24xx_serial_console
+static void samsung_early_write(struct console *con, const char *s, unsigned n)
+{
+ struct earlycon_device *dev = con->data;
+
+ uart_console_write(&dev->port, s, n, s3c24xx_serial_console_putchar);
+}
+
+static int __init samsung_early_console_setup(struct earlycon_device *device,
+ const char *opt)
+{
+ if (!device->port.membase)
+ return -ENODEV;
+ device->con->write = samsung_early_write;
+ return 0;
+}
+EARLYCON_DECLARE(samsung, samsung_early_console_setup);
#else
#define S3C24XX_SERIAL_CONSOLE NULL
#endif
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: dw_mmc: add support for ARM64
Hi Chrish, Ulf, Arnd Any comments/suggestions? On Fri, Aug 29, 2014 at 3:54 PM, Alim Akhtar wrote: > There are upcoming ARM64 SoCs with dw_mmc host controller. > > Signed-off-by: Alim Akhtar > --- > drivers/mmc/host/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig > index a43295c..72dd6c2 100644 > --- a/drivers/mmc/host/Kconfig > +++ b/drivers/mmc/host/Kconfig > @@ -580,7 +580,7 @@ config SDH_BFIN_MISSING_CMD_PULLUP_WORKAROUND > config MMC_DW > tristate "Synopsys DesignWare Memory Card Interface" > depends on HAS_DMA > - depends on ARC || ARM || MIPS || COMPILE_TEST > + depends on ARC || ARM || ARM64 || MIPS || COMPILE_TEST > help > This selects support for the Synopsys DesignWare Mobile Storage IP > block, this provides host support for SD and MMC interfaces, in both > -- > 1.7.10.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Alim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: dw_mmc: add support for ARM64
Hi Ulf, On Tue, Sep 9, 2014 at 12:21 PM, Ulf Hansson wrote: > On 29 August 2014 12:24, Alim Akhtar wrote: >> There are upcoming ARM64 SoCs with dw_mmc host controller. >> >> Signed-off-by: Alim Akhtar >> --- >> drivers/mmc/host/Kconfig |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig >> index a43295c..72dd6c2 100644 >> --- a/drivers/mmc/host/Kconfig >> +++ b/drivers/mmc/host/Kconfig >> @@ -580,7 +580,7 @@ config SDH_BFIN_MISSING_CMD_PULLUP_WORKAROUND >> config MMC_DW >> tristate "Synopsys DesignWare Memory Card Interface" >> depends on HAS_DMA >> - depends on ARC || ARM || MIPS || COMPILE_TEST >> + depends on ARC || ARM || ARM64 || MIPS || COMPILE_TEST > > Before enabling this, wouldn't it be better to add the needed support > in dw_mmc first? Or there are no changes needed? > > There are also ongoing development and discussions for exynos7, which > I guess relates to this? > http://www.spinics.net/lists/linux-mmc/msg28294.html Thanks for looking into this. Yes, this patch is being tested on exynos7 platform which is ongoing development. The above link is one of them. I feel this patch is too generic in nature and we now known at least exynos7 is going to use this. I don't know if there are any other ARM64 platform with dw_mmc controller. So, I am going to leave this upto you to decide when to take this patch, incase you decided to take it after exynos7 support lands, I will send a reminder for this. > > Kind regards > Uffe > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Alim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mmc: dw_mmc: add support for ARM64
There are upcoming ARM64 SoCs with dw_mmc host controller. Signed-off-by: Alim Akhtar --- drivers/mmc/host/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index a43295c..72dd6c2 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -580,7 +580,7 @@ config SDH_BFIN_MISSING_CMD_PULLUP_WORKAROUND config MMC_DW tristate "Synopsys DesignWare Memory Card Interface" depends on HAS_DMA - depends on ARC || ARM || MIPS || COMPILE_TEST + depends on ARC || ARM || ARM64 || MIPS || COMPILE_TEST help This selects support for the Synopsys DesignWare Mobile Storage IP block, this provides host support for SD and MMC interfaces, in both -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: dw_mmc: Remove architecture dependency
Hi Andrew, On Wed, Aug 13, 2014 at 11:02 PM, Andrew Bresticker wrote: > The dw_mmc host may also be present on non-ARC/ARM SoCs (e.g. MIPS) > and the driver itself does not appear to depend on any particular > architecture(s). > > Signed-off-by: Andrew Bresticker > --- > drivers/mmc/host/Kconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig > index a565254..15b110a 100644 > --- a/drivers/mmc/host/Kconfig > +++ b/drivers/mmc/host/Kconfig > @@ -563,7 +563,6 @@ config SDH_BFIN_MISSING_CMD_PULLUP_WORKAROUND > > config MMC_DW > tristate "Synopsys DesignWare Memory Card Interface" > - depends on ARC || ARM I am not sure if just removing _depends_ is good vs adding another architecture(s) dependency here. There are n number of places in Kconfig where this _depends_ runs up to well over 10 entries. What about config like MMC_DW_EXYNOS and MMC_DW_K3 which depends on MMC_DW? Is it ok to expose them as well for architectures which might not contains these variants? One way I found this useful, one need not worry about finding MMC_DW in there arch default menu-config, this will just appear, go and select it. Lets see what others think about this. > help > This selects support for the Synopsys DesignWare Mobile Storage IP > block, this provides host support for SD and MMC interfaces, in both > -- > 2.1.0.rc2.206.gedb03e5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Alim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] mmc: dw_mmc: Add dependency on DMA
Hi Andrew, On Thu, Aug 14, 2014 at 10:15 PM, Andrew Bresticker wrote: > The dw_mmc drivers rely on the DMA API, so update the Kconfig entry > to depend on HAS_DMA. Since the drivers should build on any platform > with DMA, allow the driver to compile tested on non-ARC/ARM platforms. > > Signed-off-by: Andrew Bresticker > --- Reviewed-by: Alim Akhtar > drivers/mmc/host/Kconfig | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig > index a565254..385674b 100644 > --- a/drivers/mmc/host/Kconfig > +++ b/drivers/mmc/host/Kconfig > @@ -563,7 +563,8 @@ config SDH_BFIN_MISSING_CMD_PULLUP_WORKAROUND > > config MMC_DW > tristate "Synopsys DesignWare Memory Card Interface" > - depends on ARC || ARM > + depends on HAS_DMA > + depends on ARC || ARM || COMPILE_TEST > help > This selects support for the Synopsys DesignWare Mobile Storage IP > block, this provides host support for SD and MMC interfaces, in both > -- > 2.1.0.rc2.206.gedb03e5 > -- Regards, Alim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] mmc: dw_mmc: Add support for MIPS
Hi Andrew, On Thu, Aug 14, 2014 at 10:15 PM, Andrew Bresticker wrote: > There are upcoming MIPS SoCs with dw_mmc hosts. > > Signed-off-by: Andrew Bresticker Reviewed-by: Alim Akhtar > --- > drivers/mmc/host/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig > index 385674b..6acc2ab 100644 > --- a/drivers/mmc/host/Kconfig > +++ b/drivers/mmc/host/Kconfig > @@ -564,7 +564,7 @@ config SDH_BFIN_MISSING_CMD_PULLUP_WORKAROUND > config MMC_DW > tristate "Synopsys DesignWare Memory Card Interface" > depends on HAS_DMA > - depends on ARC || ARM || COMPILE_TEST > + depends on ARC || ARM || MIPS || COMPILE_TEST > help > This selects support for the Synopsys DesignWare Mobile Storage IP > block, this provides host support for SD and MMC interfaces, in both > -- > 2.1.0.rc2.206.gedb03e5 > -- Regards, Alim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mmc: dw_mmc: Remove old card detect infrastructure
Hi Doug, On Wed, Oct 22, 2014 at 10:06 PM, Doug Anderson wrote: > Hi, > > On Sun, Oct 19, 2014 at 8:23 PM, Jaehoon Chung wrote: >> Hi. >> >> On 10/17/2014 09:44 PM, Alim Akhtar wrote: >>> Hi Doug, >>> >>> On Thu, Oct 16, 2014 at 9:40 PM, Doug Anderson >>> wrote: >>>> Alim, >>>> >>>> On Thu, Oct 16, 2014 at 5:57 AM, Alim Akhtar wrote: >>>>> Hi Doug, >>>>> >>>>> On Tue, Oct 14, 2014 at 10:03 PM, Doug Anderson >>>>> wrote: >>>>>> The dw_mmc driver had a bunch of code that ran whenever a card was >>>>>> ejected and inserted. However, this code was old and crufty and >>>>>> should be removed. Some evidence that it's really not needed: >>>>>> >>>>>> 1. Is is supposed to be legal to use 'cd-gpio' on dw_mmc instead of >>>>>>using the built-in card detect mechanism. The 'cd-gpio' code >>>>>>doesn't run any of the crufty old code but yet still works. >>>>>> >>>>>> 2. While looking at this, I realized that my old change (369ac86 mmc: >>>>>>dw_mmc: don't queue up a card detect at slot startup) actually >>>>>>castrated the old code a little bit already and nobody noticed. >>>>>>Specifically "last_detect_state" was left as 0 at bootup. That >>>>>>means that on the first card removal none of the crufty code ran. >>>>>> >>>>> Yes, right most of these codes are _almost_ never call. But I see >>>>> dw_mci_reset() being called on card removal (after first >>>>> insert/removal). >>>> >>>> Right. The old crufty code was called on the 2nd removal, not the >>>> 1st. That meant that the two were accidentally different. My point >>>> was that if the old code was really required that someone would have >>>> noticed crashes on the 1st removal after each boot. Since nobody is >>>> reporting crashes with that then it means it can't be too terrible. >>>> >>>> One thing to note: I remember in the last Chromebook project you were >>>> trying to track down crashes associated with constant eject / insert >>>> of SD Cards. I wonder if my patch will fix these crashes? >>>> >>> Ah, yes, reproducing that and checking with this patch will be really >>> interesting. >>> >>>> >>>>> I tested this on exynos5800 and this looks working fine. We need to >>>>> test once cross suspend/resume as well. >>>> >>>> Good idea. Can you test that? I know that there's been lots of flux >>>> with suspend/resume on exynos and I'm not sure I have all the latest >>>> patches, but I'll search for them if you are unable to test easily. >>>> >>> Sure, I will do that..but probably sometime next week, as I will out >>> of office for few days. >>>> >>>>> And as Jaehoon pointed out,probably lets look in TRM if there are some >>>>> recommended steps for cd-detect. >>>>> Otherwise this looks good to me. >>>> >>>> If you see some other requirement than the one I addressed in my email >>>> to Jaehoon, please let me know. >> >> I know there is no other requirement for detecting card. >> So this patch can be applied after testing the above case(suspend/resume). > > I put a kernel based upon 3.17 on an exynos5250-snow (specifically > git://git.collabora.co.uk/git/user/javier/linux.git branch > max77802-op-modes-v3, git hash 98cf5a0). Snow uses the builtin card > detect on dw_mmc. Resume wasn't terribly reliable to start with even > without my patch (it often woke up right after suspend), but it worked > well enough for testing. I tested the following scenarios: > > 1. Leave card in and mounted. Suspend/resume. Card is still usable > after resume > > 2. Suspend and insert card. Resume. Card is detected upon resume. > > 3. Suspend and remove card. Resume. Card is removed upon resume. > > How does that sound? > Sounds good to me. I tested this on Peach-Pi with v3.17 based kernel across suspend resume and cards works fine. Even I back-ported this to chromium 3.8 and tested on peach-pi, no issue over a hundred s2r cycles. Tested-by: alim.akhtar > -Doug -- Regards, Alim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
