[PATCH] ARM: Exynos4: fixed SYSMMU setup definition to mate parameter name
This is trivial patch to mate parameter name between iommu api enabled case and
disabled case.
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-exynos/include/mach/sysmmu.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/sysmmu.h
b/arch/arm/mach-exynos/include/mach/sysmmu.h
index 998daf2..81e4c66 100644
--- a/arch/arm/mach-exynos/include/mach/sysmmu.h
+++ b/arch/arm/mach-exynos/include/mach/sysmmu.h
@@ -58,7 +58,7 @@ static inline void platform_set_sysmmu(
#endif
#else /* !CONFIG_EXYNOS_DEV_SYSMMU */
-#define platform_set_sysmmu(dev, sysmmu) do { } while (0)
+#define platform_set_sysmmu(sysmu, dev) do { } while (0)
#endif
#define SYSMMU_CLOCK_DEVNAME(ipname, id) (SYSMMU_DEVNAME_BASE . #id)
--
1.7.4.1
--
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
[RESEND][PATCH] ARM: Exynos4: fixed SYSMMU setup definition to mate parameter name
This is trivial patch to mate parameter name between iommu api enabled case and
disabled case.
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Sorry about typo in previous patch.
arch/arm/mach-exynos/include/mach/sysmmu.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/sysmmu.h
b/arch/arm/mach-exynos/include/mach/sysmmu.h
index 998daf2..81e4c66 100644
--- a/arch/arm/mach-exynos/include/mach/sysmmu.h
+++ b/arch/arm/mach-exynos/include/mach/sysmmu.h
@@ -58,7 +58,7 @@ static inline void platform_set_sysmmu(
#endif
#else /* !CONFIG_EXYNOS_DEV_SYSMMU */
-#define platform_set_sysmmu(dev, sysmmu) do { } while (0)
+#define platform_set_sysmmu(sysmmu, dev) do { } while (0)
#endif
#define SYSMMU_CLOCK_DEVNAME(ipname, id) (SYSMMU_DEVNAME_BASE . #id)
--
1.7.4.1
--
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
Re: [PATCH] gpio: samsung: add devicetree init for s3c24xx arches
Hi Thomas,
thanks for your review:
Am Montag, 27. August 2012, 06:20:49 schrieb Thomas Abraham:
Hi Heiko,
On 26 August 2012 03:23, Heiko Stübner he...@sntech.de wrote:
Until now the Exynos-SoC was the only Samsung-SoC supporting the GPIOs
via the device tree. This patch implements dt-support for the
s3c24xx arches.
The controllers contain only 3 cells, as the underlying gpio controller
does not support controlling the drive strength on a gpio level.
Tested with the gpio-keys driver on a s3c2416 based machine.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
.../devicetree/bindings/gpio/gpio-samsung.txt | 38
drivers/gpio/gpio-samsung.c| 63
2 files changed, 101 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt index
5375625..ce6a7d4 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
@@ -39,3 +39,41 @@ Example:
#gpio-cells = 4;
gpio-controller;
};
+
+
+Samsung S3C24XX GPIO Controller
+
+Required properties:
+- compatible: Compatible property value should be
samsung,s3c24xx-gpio.
This is debatable, but I would choose to be specific here and use
samsing,s3c2416-gpio. For instance, SoC's in s3c24xx family have
differing value for pull none/down/up.
Hmmm, but the logic to drive the gpio controller is the same for all arches.
The only difference is the number to use for the different pull up/down
settings. So I think the samsung,s3c24xx-gpio is ok but the documentation
should simply reflect the different pull settings.
+
+- reg: Physical base address of the controller and length of memory
mapped + region.
+
+- #gpio-cells: Should be 3. The syntax of the gpio specifier used by
client nodes + should be the following with values derived from the SoC
user manual. + [phandle of the gpio controller node]
+ [pin number within the gpio controller]
+ [mux function]
+ [flags and pull up/down]
+
+ Values for gpio specifier:
+ - Pin number: depending on the controller a number from 0 up to 15.
+ - Flags and Pull Up/Down: 0 - Pull Up/Down Disabled.
+1 - Pull Down Enabled.
+3 - Pull Up Enabled.
As per s3c2416 user manual, 2 is used for Pull Up and 3 is listed as
reserved value. Any particular reason to use 3 here for pull up and
not 2 as per the user manual?
Sorry, copy and paste error :-)
+ Bit 16 (0x0001) - Input is active low.
+
+- gpio-controller: Specifies that the node is a gpio controller.
+- #address-cells: should be 1.
+- #size-cells: should be 1.
It would be informative to add information about the 'mux function'
cell here as well. Specifically, on how to handle the banks that have
an extended GPxSEL register that allow additional pin function
selection.
Will add a mux function description.
Until now I've never realised the existence of the GPxSEL registers, so thanks
for the pointer :-).
But is this used in the driver at all? All the setcfg/getcfg functions in
gpio-samsung.c only handle the GPxCON registers - I haven't found code to
handle the GPxSEL registers at all. So my guess is that this was never
implemented - or that I'm blind ;-) .
+
+Example:
+
+ gpa: gpio-controller@5600 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = samsung,s3c24xx-gpio;
+ reg = 0x5600 0x10;
+ #gpio-cells = 3;
+ gpio-controller;
+ };
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index a150d2e..80a2817 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -938,6 +938,67 @@ static void __init samsung_gpiolib_add(struct
samsung_gpio_chip *chip)
s3c_gpiolib_track(chip);
}
+#if defined(CONFIG_PLAT_S3C24XX) defined(CONFIG_OF)
+static int s3c24xx_gpio_xlate(struct gpio_chip *gc,
+ const struct of_phandle_args *gpiospec, u32
*flags) +{
+ unsigned int pin;
+
+ if (WARN_ON(gc-of_gpio_n_cells 3))
+ return -EINVAL;
+
+ if (WARN_ON(gpiospec-args_count gc-of_gpio_n_cells))
+ return -EINVAL;
+
+ if (gpiospec-args[0] gc-ngpio)
+ return -EINVAL;
+
+ pin = gc-base + gpiospec-args[0];
+
+ if (s3c_gpio_cfgpin(pin, S3C_GPIO_SFN(gpiospec-args[1])))
+ pr_warn(gpio_xlate: failed to set pin function\n);
+ if (s3c_gpio_setpull(pin, gpiospec-args[2] 0x))
+ pr_warn(gpio_xlate: failed to set pin pull up/down\n);
Re: [PATCH] gpio: samsung: add devicetree init for s3c24xx arches
Hi, On Mon, Aug 27, 2012 at 11:01 AM, Heiko Stübner he...@sntech.de wrote: Hi Thomas, thanks for your review: Hmmm, but the logic to drive the gpio controller is the same for all arches. The only difference is the number to use for the different pull up/down settings. So I think the samsung,s3c24xx-gpio is ok but the documentation should simply reflect the different pull settings. Also s3c2410 and s3c2440 has different count of GPIOs. And that could be a problem on machines with GPIO-expanders (h1940 machine) It would be informative to add information about the 'mux function' cell here as well. Specifically, on how to handle the banks that have an extended GPxSEL register that allow additional pin function selection. Will add a mux function description. Until now I've never realised the existence of the GPxSEL registers, so thanks for the pointer :-). But is this used in the driver at all? All the setcfg/getcfg functions in gpio-samsung.c only handle the GPxCON registers - I haven't found code to handle the GPxSEL registers at all. So my guess is that this was never implemented - or that I'm blind ;-) . There're no GPxSEL registers on s3c2410/s3c2440/s3c2442. Is it something s3c2412/sec2416 specific? Regards Vasily -- 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
Re: [PATCH v4 9/9] mmc: dw_mmc: add support for exynos specific implementation of dw-mshc
Hi Thomas,
+ gpio = of_get_named_gpio(slot_np, wp-gpios, 0);
+ if (gpio_is_valid(gpio)) {
+ if (devm_gpio_request(host-dev, gpio, dw-mci-wp))
+ dev_info(host-dev, gpio [%d] request failed\n,
+ gpio);
+ } else {
+ dev_info(host-dev, wp gpio not available);
+ host-pdata-quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
+ }
+
+ if (host-pdata-quirks DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
+ return 0;
+
+ gpio = of_get_named_gpio(slot_np, samsung,cd-pinmux-gpio, 0);
+ if (gpio_is_valid(gpio)) {
+ if (devm_gpio_request(host-dev, gpio, dw-mci-cd))
I'm not sure, but i saw mmc_gpio_request_cd() into drivers/mmc/core/slot-gpio.c.
Can we use this? i think we can use them.
Just my opinion.
Best Regards,
Jaehoon Chung
+ dev_err(host-dev, gpio [%d] request failed\n, gpio);
+ } else {
+ dev_info(host-dev, cd gpio not available);
+ }
+
+ return 0;
+}
+
+/* Exynos5250 controller specific capabilities */
+static unsigned long exynos5250_dwmmc_caps[4] = {
+ MMC_CAP_UHS_DDR50 | MMC_CAP_1_8V_DDR |
+ MMC_CAP_8_BIT_DATA | MMC_CAP_CMD23,
+ MMC_CAP_CMD23,
+ MMC_CAP_CMD23,
+ MMC_CAP_CMD23,
+};
+
+static struct dw_mci_drv_data exynos5250_drv_data = {
+ .caps = exynos5250_dwmmc_caps,
+ .init = dw_mci_exynos_priv_init,
+ .prepare_command= dw_mci_exynos_prepare_command,
+ .set_ios= dw_mci_exynos_set_ios,
+ .parse_dt = dw_mci_exynos_parse_dt,
+ .setup_bus = dw_mci_exynos_setup_bus,
+};
+
+static const struct of_device_id dw_mci_exynos_match[] = {
+ { .compatible = samsung,exynos5250-dw-mshc,
+ .data = (void *)exynos5250_drv_data, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, dw_mci_pltfm_match);
+
+int dw_mci_exynos_probe(struct platform_device *pdev)
+{
+ struct dw_mci_drv_data *drv_data;
+ const struct of_device_id *match;
+
+ match = of_match_node(dw_mci_exynos_match, pdev-dev.of_node);
+ drv_data = match-data;
+ return dw_mci_pltfm_register(pdev, drv_data);
+}
+
+static struct platform_driver dw_mci_exynos_pltfm_driver = {
+ .probe = dw_mci_exynos_probe,
+ .remove = __exit_p(dw_mci_pltfm_remove),
+ .driver = {
+ .name = dwmmc_exynos,
+ .of_match_table = of_match_ptr(dw_mci_exynos_match),
+ .pm = dw_mci_pltfm_pmops,
+ },
+};
+
+module_platform_driver(dw_mci_exynos_pltfm_driver);
+
+MODULE_DESCRIPTION(Samsung Specific DW-MSHC Driver Extension);
+MODULE_AUTHOR(Thomas Abraham thomas...@samsung.com);
+MODULE_LICENSE(GPL v2);
+MODULE_ALIAS(platform:dwmmc-exynos);
--
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
Re: [PATCH v4 0/9] mmc: dw_mmc: add support for device tree based instantiation
On Sun, Aug 26, 2012 at 12:51 PM, Thomas Abraham thomas.abra...@linaro.org wrote: This is the fourth version of the patch series that adds device tree support for Synopsis Designware Mobile Storage Host Controller. In this version, the significant change is the spliting of Exynos specific code into a seperate file, as suggested by Seungwon Jeon tgih@samsung.com. Spliting the Exynos specific code into a seperate file did infact keeps the core driver code clean, which otherwise was littered with Exynos specific code. I hope the changes look sane, though. This has been tested only on smdk5250 board. Thomas Abraham (9): mmc: dw_mmc: convert copy of struct device in struct dw_mci to a reference mmc: dw_mmc: Use devm_* functions in dw_mmc platform driver mmc: dw_mmc: allow probe to succeed even if one slot is initialized mmc: dw_mmc: lookup for optional biu and ciu clocks mmc: dw_mmc: add quirk to indicate missing write protect line mmc: dw_mmc: add device tree support mmc: dw_mmc: prepare functions in dw_mmc-pltfm for reuse mmc: dw_mmc: add support for implementation specific callbacks mmc: dw_mmc: add support for exynos specific implementation of dw-mshc .../devicetree/bindings/mmc/exynos-dw-mshc.txt | 79 ++ .../devicetree/bindings/mmc/synposis-dw-mshc.txt | 90 ++ drivers/mmc/host/Kconfig |9 + drivers/mmc/host/Makefile |3 +- drivers/mmc/host/dw_mmc-exynos.c | 247 + drivers/mmc/host/dw_mmc-pci.c |2 +- drivers/mmc/host/dw_mmc-pltfm.c| 62 +++-- drivers/mmc/host/dw_mmc-pltfm.h| 20 ++ drivers/mmc/host/dw_mmc.c | 287 drivers/mmc/host/dw_mmc.h | 22 ++ include/linux/mmc/dw_mmc.h | 13 +- 11 files changed, 757 insertions(+), 77 deletions(-) create mode 100644 Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt create mode 100644 Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt create mode 100644 drivers/mmc/host/dw_mmc-exynos.c create mode 100644 drivers/mmc/host/dw_mmc-pltfm.h This series looks good to me, although I am not familiar enough with the device tree stuff to review it in a meaningful way. Acked-by: Will Newton will.new...@imgtec.com Note that the platform driver changes will conflict with Jaehoon Chung's patch to fix a section mismatch in that file. Have you tried building this as a module and with section mismatch debugging to make sure the new code does not add any mismatches? -- 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
Re: [PATCH] gpio: samsung: add devicetree init for s3c24xx arches
Hi Vasily,
Am Montag, 27. August 2012, 10:57:04 schrieb Vasily Khoruzhick:
Hi,
On Mon, Aug 27, 2012 at 11:01 AM, Heiko Stübner he...@sntech.de wrote:
Hi Thomas,
thanks for your review:
Hmmm, but the logic to drive the gpio controller is the same for all
arches. The only difference is the number to use for the different pull
up/down settings. So I think the samsung,s3c24xx-gpio is ok but the
documentation should simply reflect the different pull settings.
Also s3c2410 and s3c2440 has different count of GPIOs. And that could
be a problem on machines
with GPIO-expanders (h1940 machine)
I'm not sure I follow :-) .
The compatible property here only sets the mechanism on how to handle the
gpios defined in the devicetree - here to use the s3c24xx-style. As you can
see in gpio-samsung.c the handling is already unified for all the s3c24xx
architectures.
The definition of what gpio banks exist is then done in the respective
devicetree file for the individual SoC. And of course here one would have
individual definitions, depending on the banks present.
For reference my quite empty s3c2416.dtsi file currently looks like:
/include/ skeleton.dtsi
/ {
compatible = samsung,s3c2416;
cpus {
cpu@0 {
compatible = arm,arm926ejs;
};
};
gpio-controllers {
#address-cells = 1;
#size-cells = 1;
gpio-controller;
ranges;
gpa: gpio-controller@5600 {
compatible = samsung,s3c24xx-gpio;
reg = 0x5600 0x10;
#gpio-cells = 3;
};
gpb: gpio-controller@5610 {
compatible = samsung,s3c24xx-gpio;
reg = 0x5610 0x10;
#gpio-cells = 3;
};
gpc: gpio-controller@5620 {
compatible = samsung,s3c24xx-gpio;
reg = 0x5620 0x10;
#gpio-cells = 3;
};
gpd: gpio-controller@5630 {
compatible = samsung,s3c24xx-gpio;
reg = 0x5630 0x10;
#gpio-cells = 3;
};
gpe: gpio-controller@5640 {
compatible = samsung,s3c24xx-gpio;
reg = 0x5640 0x10;
#gpio-cells = 3;
};
gpf: gpio-controller@5650 {
compatible = samsung,s3c24xx-gpio;
reg = 0x5650 0x10;
#gpio-cells = 3;
};
gpg: gpio-controller@5660 {
compatible = samsung,s3c24xx-gpio;
reg = 0x5660 0x10;
#gpio-cells = 3;
};
gph: gpio-controller@5670 {
compatible = samsung,s3c24xx-gpio;
reg = 0x5670 0x10;
#gpio-cells = 3;
};
/* s3c2443 and later */
gpj: gpio-controller@56D0 {
compatible = samsung,s3c24xx-gpio;
reg = 0x56D0 0x10;
#gpio-cells = 3;
};
gpk: gpio-controller@56E0 {
compatible = samsung,s3c24xx-gpio;
reg = 0x56E0 0x10;
#gpio-cells = 3;
};
gpl: gpio-controller@56F0 {
compatible = samsung,s3c24xx-gpio;
reg = 0x56F0 0x10;
#gpio-cells = 3;
};
gpm: gpio-controller@56000100 {
compatible = samsung,s3c24xx-gpio;
reg = 0x56000100 0x10;
#gpio-cells = 3;
};
};
};
Other s3c24xx SoCs would of course need to define their own.
It would be informative to add information about the 'mux function'
cell here as well. Specifically, on how to handle the banks that have
an extended GPxSEL register that allow additional pin function
selection.
Will add a mux function description.
Until now I've never realised the existence of the GPxSEL registers, so
thanks for the pointer :-).
But is this used in the driver at all? All the setcfg/getcfg functions in
gpio-samsung.c only handle the GPxCON registers - I haven't found code to
handle the GPxSEL registers at all. So my guess is that this was never
implemented - or that I'm blind ;-) .
There're no GPxSEL registers on s3c2410/s3c2440/s3c2442. Is it
something s3c2412/sec2416 specific?
s3c2412 also does not have it ... it seems entirely
Re: [PATCH] gpio: samsung: add devicetree init for s3c24xx arches
On Mon, Aug 27, 2012 at 12:44 PM, Heiko Stübner he...@sntech.de wrote:
Hi Vasily,
I'm not sure I follow :-) .
The compatible property here only sets the mechanism on how to handle the
gpios defined in the devicetree - here to use the s3c24xx-style. As you can
see in gpio-samsung.c the handling is already unified for all the s3c24xx
architectures.
The definition of what gpio banks exist is then done in the respective
devicetree file for the individual SoC. And of course here one would have
individual definitions, depending on the banks present.
For reference my quite empty s3c2416.dtsi file currently looks like:
/include/ skeleton.dtsi
/ {
compatible = samsung,s3c2416;
cpus {
cpu@0 {
compatible = arm,arm926ejs;
};
};
gpio-controllers {
#address-cells = 1;
#size-cells = 1;
gpio-controller;
ranges;
gpa: gpio-controller@5600 {
compatible = samsung,s3c24xx-gpio;
reg = 0x5600 0x10;
#gpio-cells = 3;
};
gpb: gpio-controller@5610 {
compatible = samsung,s3c24xx-gpio;
reg = 0x5610 0x10;
#gpio-cells = 3;
};
gpc: gpio-controller@5620 {
compatible = samsung,s3c24xx-gpio;
reg = 0x5620 0x10;
#gpio-cells = 3;
};
gpd: gpio-controller@5630 {
compatible = samsung,s3c24xx-gpio;
reg = 0x5630 0x10;
#gpio-cells = 3;
};
gpe: gpio-controller@5640 {
compatible = samsung,s3c24xx-gpio;
reg = 0x5640 0x10;
#gpio-cells = 3;
};
gpf: gpio-controller@5650 {
compatible = samsung,s3c24xx-gpio;
reg = 0x5650 0x10;
#gpio-cells = 3;
};
gpg: gpio-controller@5660 {
compatible = samsung,s3c24xx-gpio;
reg = 0x5660 0x10;
#gpio-cells = 3;
};
gph: gpio-controller@5670 {
compatible = samsung,s3c24xx-gpio;
reg = 0x5670 0x10;
#gpio-cells = 3;
};
/* s3c2443 and later */
gpj: gpio-controller@56D0 {
compatible = samsung,s3c24xx-gpio;
reg = 0x56D0 0x10;
#gpio-cells = 3;
};
gpk: gpio-controller@56E0 {
compatible = samsung,s3c24xx-gpio;
reg = 0x56E0 0x10;
#gpio-cells = 3;
};
gpl: gpio-controller@56F0 {
compatible = samsung,s3c24xx-gpio;
reg = 0x56F0 0x10;
#gpio-cells = 3;
};
gpm: gpio-controller@56000100 {
compatible = samsung,s3c24xx-gpio;
reg = 0x56000100 0x10;
#gpio-cells = 3;
};
};
};
Other s3c24xx SoCs would of course need to define their own.
I see. But how does it handle GPA bank (which is output-only, and
GPACON differs a bit from GP{B-J}CON? And some banks has lower number
(not 16) of GPIOs, like GPH.
Also, what would be value for S3C_GPIO_END?
Regards
Vasily
--
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
RE: [PATCH] ARM: EXYNOS: Add MFC device tree support
Hi Kgene,
Thank you for the review comments.
Please find my response inline.
On Thu, Aug 23, 2012 at 1:46 PM, Kukjin Kim kgene@samsung.com wrote:
Arun Kumar K wrote:
Hi Thomas,
Thank you for the comments.
Please find my response inline.
--- Original Message ---
Sender : Thomas Abrahamthomas.abra...@linaro.org
Date : Aug 16, 2012 17:12 (GMT+05:30)
Title : Re: [PATCH] ARM: EXYNOS: Add MFC device tree support
On 16 August 2012 18:01, Arun Kumar K arun...@samsung.com wrote:
From: Naveen Krishna Chatradhi ch.nav...@samsung.com
This patch adds device tree entry for MFC in the Exynos
machines. Exynos4 SoCs support MFC v5 version and Exynos5 has
MFC v6.x version. So making the required changes in the clock
Since v6.1 is not used anywhere so just MFC v6 should be ok.
Ok.
files and adds MFC to the DT device list.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
---
.../devicetree/bindings/media/s5p-mfc.txt | 24
arch/arm/boot/dts/exynos4210.dtsi | 10
arch/arm/boot/dts/exynos5250.dtsi | 10
arch/arm/mach-exynos/clock-exynos5.c |2 +-
arch/arm/mach-exynos/mach-exynos4-dt.c | 22
++
arch/arm/mach-exynos/mach-exynos5-dt.c | 22
++
6 files changed, 89 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/s5p-mfc.txt
diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt
b/Documentation/devicetree/bindings/media/s5p-mfc.txt
new file mode 100644
index 000..b9bd266
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -0,0 +1,24 @@
+* Samsung Multi Format Codec (MFC)
+
+Mult Format Codec (MFC) is the IP present in Samsung SoCs which
+supports high resolution decoding and encoding functionalities.
In addition to this, specifying that mfc is used for video
encode/decode would be informative.
Ok. I will make it more descriptive.
+
+Required properties:
+ - compatible : value should be either one among the following
+ (a) samsung,s5p-mfc-v5 for MFC v5 present in Exynos4 SoCs
+ (b) samsung,s5p-mfc-v6 for MFC v6.x present in Exynos5 SoCs
s5p should be dropped from the compatible values. For example, it
should be samsung,mfc-v5, which is sufficient to identify the
version of the mfc controller.
Ok will remove s5p.
Yeah, I agree, just 'mfc-vX' is enough.
Ok. Will change it.
+
+ - reg : Physical base address of the IP registers and length of
memory
+ mapped region.
+
+ - interrupts : MFC interupt number to the CPU.
+
+ - samsung,mfc-r : Base address of the first memory bank used by MFC
+ for DMA contiguous memory allocation.
+
+ - samsung,mfc-r-size : Size of the first memory bank.
It is not allowed to pass buffer base address and size from device
tree. Device tree node should describe only the MFC controller
hardware. Any memory management related information should be handled
outside of device tree. This helps the bindings to be reusable across
multiple operating systems.
The mfc-l and mfc-r base address and size is board specific info which has
to
be passed to the driver. This is used for DMA contiguous allocation by
driver and this value
can change on a different board.
So in that case, i will pass it as platform data to the driver from mach-
exynos5-dt.c file.
I hope that would be ok.
I don't think so. The mach-exynos5-dt is for all EXYNOS5 SoCs not
platform_data. As I know, the addresses and sizes for buffer passed via
platform data before, so it can be passed via device tree for board(.dtsi)?
not SoC. In addition, it depends on board.
Ok. So as suggested the best option would be to move the mfc-l and r
base address and size information to board dts file
(exynos5250-smdk5250.dts) from exynos5250.dtsi. Hope this would be
good.
+
+ - samsung,mfc-l : Base address of the second memory bank used by MFC
+ for DMA contiguous memory allocation.
+
+ - samsung,mfc-l-size : Size of the second memory bank.
Same comment as above. And the bindings documentation is usually
included in the same patch that adds device tree support for the
driver.
Ok
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 02891fe..b5ee43d 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -56,6 +56,16 @@
interrupts = 0 43 0;
};
+ mfc {
+ compatible = samsung,s5p-mfc;
Maybe
+ compatible = samsung,mfc-v5; ?
+ reg = 0x1340 0x1;
+ interrupts = 0 94 0;
+ samsung,mfc-r = 0x4300;
+
Re: [RESEND][PATCH] ARM: Exynos4: fixed SYSMMU setup definition to mate parameter name
On Mon, Aug 27, 2012 at 4:11 PM, Seung-Woo Kim sw0312@samsung.com wrote:
This is trivial patch to mate parameter name between iommu api enabled case
and
disabled case.
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Sorry about typo in previous patch.
arch/arm/mach-exynos/include/mach/sysmmu.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/sysmmu.h
b/arch/arm/mach-exynos/include/mach/sysmmu.h
index 998daf2..81e4c66 100644
--- a/arch/arm/mach-exynos/include/mach/sysmmu.h
+++ b/arch/arm/mach-exynos/include/mach/sysmmu.h
@@ -58,7 +58,7 @@ static inline void platform_set_sysmmu(
#endif
#else /* !CONFIG_EXYNOS_DEV_SYSMMU */
-#define platform_set_sysmmu(dev, sysmmu) do { } while (0)
+#define platform_set_sysmmu(sysmmu, dev) do { } while (0)
#endif
Thank you for your correction.
KyongHo
--
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
Re: ASoC: SAMSUNG: Change Kconfig to support all EXYNOSs
On Sun, Aug 26, 2012 at 05:04:37PM +0900, �ڻ��� wrote: All EXYNOSs use SND_SOC_SAMSUNG configuration. This patch change Kconfig to support all EXYNOSs like EXYNOS4 and EXYNOS5. git can't figure out how to apply your patch due to your character set: fatal: cannot convert from ks_c_5601-1987 to UTF-8 -- 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
Re: [PATCH] spi/s3c64xx: Drop extra calls to spi_master_get in suspend/remove functions
On Thu, Aug 16, 2012 at 08:14:25PM -0700, Guenter Roeck wrote: Suspend and resume functions call spi_master_get() without matching spi_master_put(). The extra references are unnecessary and cause subsequent module unload attempts to fail. Drop the calls. Applied, thanks. -- 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
Re: ASoC: SAMSUNG: Change Kconfig to support all EXYNOSs
On 08/26/12 01:04, 박상수 wrote: All EXYNOSs use SND_SOC_SAMSUNG configuration. This patch change Kconfig to support all EXYNOSs like EXYNOS4 and EXYNOS5. Signed-off-by: Sangsu Parksangsu4u.p...@samsung.com --- sound/soc/samsung/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig index f17dd25..9e64ae6 100644 --- a/sound/soc/samsung/Kconfig +++ b/sound/soc/samsung/Kconfig @@ -1,6 +1,6 @@ config SND_SOC_SAMSUNG tristate ASoC support for Samsung - depends on ARCH_S3C24XX || ARCH_S3C64XX || ARCH_S5PC100 || ARCH_S5PV210 || ARCH_S5P64X0 || ARCH_EXYNOS4 + depends on ARCH_S3C24XX || ARCH_S3C64XX || ARCH_S5PC100 || ARCH_S5PV210 || ARCH_S5P64X0 || ARCH_EXYNOS Hmm, all of Samsung stuff is available...so how about? + depends on PLAT_SAMSUNG Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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
Re: [RESEND][PATCH] ARM: Exynos4: fixed SYSMMU setup definition to mate parameter name
On 08/27/12 04:59, KyongHo Cho wrote:
On Mon, Aug 27, 2012 at 4:11 PM, Seung-Woo Kimsw0312@samsung.com wrote:
This is trivial patch to mate parameter name between iommu api enabled case and
disabled case.
Signed-off-by: Seung-Woo Kimsw0312@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
Sorry about typo in previous patch.
arch/arm/mach-exynos/include/mach/sysmmu.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/sysmmu.h
b/arch/arm/mach-exynos/include/mach/sysmmu.h
index 998daf2..81e4c66 100644
--- a/arch/arm/mach-exynos/include/mach/sysmmu.h
+++ b/arch/arm/mach-exynos/include/mach/sysmmu.h
@@ -58,7 +58,7 @@ static inline void platform_set_sysmmu(
#endif
#else /* !CONFIG_EXYNOS_DEV_SYSMMU */
-#define platform_set_sysmmu(dev, sysmmu) do { } while (0)
+#define platform_set_sysmmu(sysmmu, dev) do { } while (0)
#endif
Thank you for your correction.
OK, applied with KyongHo's ack.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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
Re: [PATCH] ASoC: SAMSUNG: Add SND_SOC_DAIFMT_CONT option for snd_soc_set_fmt()
On Sun, Aug 26, 2012 at 05:45:54PM +0900, �ڻ��� wrote: SND_SOC_DAIFMT_CONT option is now needed because of below commit: ASoC: Allow DAI formats to be specified in the dai_link Clearly it's not a direct consequence of this commit, that just introduces a new optional facility which... /* Set the cpu DAI configuration */ ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_DSP_B + | SND_SOC_DAIFMT_CONT | SND_SOC_DAIFMT_IB_NF | SND_SOC_DAIFMT_CBS_CFS); ...isn't being used by the driver. Looking at the above it looks like the PCM driver is doing something very odd - _CONT doesn't make a whole lot of sense on the slave side, it's related to the clock generation so should have no effect at all on the slave side. The driver code looks reasonably sensible though. What specifically is going wrong here? -- 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
Re: [PATCH v3 3/3] ARM: dts: Add nodes for dw_mmc controllers for Samsung Exynos5250 platforms
On 08/26/12 04:59, Thomas Abraham wrote:
Add device nodes for the four instances of dw_mmc controllers in Exynos5250
and enable instance 0 and 2 for the smdk5250 board.
Signed-off-by: Thomas Abrahamthomas.abra...@linaro.org
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 57 -
arch/arm/boot/dts/exynos5250.dtsi | 32
2 files changed, 88 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 8a5e348..6dc9faf 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -16,12 +16,19 @@
model = SAMSUNG SMDK5250 board based on EXYNOS5250;
compatible = samsung,smdk5250, samsung,exynos5250;
+ aliases {
+ mshc0 =mshc_0;
+ mshc1 =mshc_1;
+ mshc2 =mshc_2;
+ mshc3 =mshc_3;
+ };
+
memory {
reg =0x4000 0x8000;
};
chosen {
- bootargs = root=/dev/ram0 rw ramdisk=8192
console=ttySAC1,115200;
+ bootargs = root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M
console=ttySAC2,115200 init=/linuxrc;
Yes, we need to sort out the 'bootargs' for using uart2 as a console,
but you know, this should be separated :-)
};
i2c@12C6 {
@@ -72,6 +79,54 @@
status = disabled;
};
+ mshc_0: dwmmc0@1220 {
How about to keep the consistent naming? dwmmc or dw_mmc? I think,
'dw_mmc' makes more sense?
+ num-slots =1;
+ supports-highspeed;
+ broken-cd;
+ fifo-depth =0x80;
+ card-detect-delay =200;
+ samsung,dw-mshc-sdr-timing =2 3 3;
+ samsung,dw-mshc-ddr-timing =1 2 3;
We need to think again the name of dw-mshc-sdr-timing, dw-mshc-ddr-timing?
[...]
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 004aaa8..f69e389 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -182,6 +182,38 @@
#size-cells =0;
};
+ dwmmc0@1220 {
+ compatible = samsung,exynos5250-dw-mshc;
I'm not sure, 'exynos5250-dw-mshc' is right here. Because it is just
dw_mmc controller on exynos5250. So...hmm...
[...]
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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
Re: [PATCH] ARM: S3C24XX: Add .get_rate callback for camif-upll clock
On 08/27/12 13:12, Sylwester Nawrocki wrote:
Add missing get_rate callback for the camif-upll clock, so frequency
of this clock is properly reported with clk_get_rate().
Signed-off-by: Sylwester Nawrockisylvester.nawro...@gmail.com
---
arch/arm/mach-s3c24xx/clock-s3c2440.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/clock-s3c2440.c
b/arch/arm/mach-s3c24xx/clock-s3c2440.c
index cb2883d..749220f 100644
--- a/arch/arm/mach-s3c24xx/clock-s3c2440.c
+++ b/arch/arm/mach-s3c24xx/clock-s3c2440.c
@@ -87,6 +87,19 @@ static int s3c2440_camif_upll_setrate(struct clk *clk,
unsigned long rate)
return 0;
}
+static unsigned long s3c2440_camif_upll_getrate(struct clk *clk)
+{
+ unsigned long parent_rate = clk_get_rate(clk-parent);
+ unsigned long camdivn = __raw_readl(S3C2440_CAMDIVN);
+
+ if (!(camdivn S3C2440_CAMDIVN_CAMCLK_SEL))
+ return parent_rate;
+
+ camdivn= S3C2440_CAMDIVN_CAMCLK_MASK;
+
+ return parent_rate / (camdivn + 1) / 2;
Well, why do we need '/ 2' here?
+}
+
/* Extra S3C2440 clocks */
static struct clk s3c2440_clk_cam = {
@@ -99,6 +112,7 @@ static struct clk s3c2440_clk_cam_upll = {
.name = camif-upll,
.ops=(struct clk_ops) {
.set_rate = s3c2440_camif_upll_setrate,
+ .get_rate = s3c2440_camif_upll_getrate,
.round_rate = s3c2440_camif_upll_round,
},
};
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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
Re: [PATCH v3 2/3] ARM: Exynos5: Add AUXDATA support for MSHC controllers
On 08/26/12 04:59, Thomas Abraham wrote:
Add entries if MSHC controllers in AUXDATA table for correct device name
initialization.
Signed-off-by: Abhilash Kesavana.kesa...@samsung.com
Signed-off-by: Thomas Abrahamthomas.abra...@linaro.org
---
arch/arm/mach-exynos/include/mach/map.h |1 +
arch/arm/mach-exynos/mach-exynos5-dt.c |8
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 9d1f3ac..5b0ee41 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -172,6 +172,7 @@
#define EXYNOS4_PA_HSMMC(x) (0x1251 + ((x) * 0x1))
#define EXYNOS4_PA_DWMCI 0x1255
+#define EXYNOS5_PA_DWMCI(x)(0x1220 + ((x) * 0x1))
Just, how about EXYNOS5_PA_DWMMC0, EXYNOS5_PA_DWMMC1, ... EXYNOS_PA_DWMMC3?
And if the addresses are different on other EXYNOS5 SoC, how do we
handle it for auxdata?
#define EXYNOS4_PA_HSOTG 0x1248
#define EXYNOS4_PA_USB_HSPHY 0x125B
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index ef770bc..4257cc1 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -47,6 +47,14 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[] __initconst = {
s3c2440-i2c.0, NULL),
OF_DEV_AUXDATA(samsung,s3c2440-i2c, EXYNOS5_PA_IIC(1),
s3c2440-i2c.1, NULL),
+ OF_DEV_AUXDATA(samsung,exynos5250-dw-mshc, EXYNOS5_PA_DWMCI(0),
As I commented, how about just 'samsung,dw-mmc'? but I'm not sure.
+ dw_mmc.0, NULL),
+ OF_DEV_AUXDATA(samsung,exynos5250-dw-mshc, EXYNOS5_PA_DWMCI(1),
+ dw_mmc.1, NULL),
+ OF_DEV_AUXDATA(samsung,exynos5250-dw-mshc, EXYNOS5_PA_DWMCI(2),
+ dw_mmc.2, NULL),
+ OF_DEV_AUXDATA(samsung,exynos5250-dw-mshc, EXYNOS5_PA_DWMCI(3),
+ dw_mmc.3, NULL),
OF_DEV_AUXDATA(samsung,exynos4210-spi, EXYNOS5_PA_SPI0,
exynos4210-spi.0, NULL),
OF_DEV_AUXDATA(samsung,exynos4210-spi, EXYNOS5_PA_SPI1,
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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
Re: [PATCH v3 1/3] ARM: Samsung: Add support for MSHC controller clocks
On 08/26/12 04:59, Thomas Abraham wrote:
Add clock instances for bus interface unit clock and card interface unit
clock of the all four MSHC controller instances.
Signed-off-by: Abhilash Kesavana.kesa...@samsung.com
Signed-off-by: Thomas Abrahamthomas.abra...@linaro.org
---
arch/arm/mach-exynos/clock-exynos5.c | 45 --
1 files changed, 16 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index 3b00e29..16d8bef 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -564,35 +564,30 @@ static struct clk exynos5_init_clocks_off[] = {
.enable = exynos5_clk_ip_peris_ctrl,
.ctrlbit= (1 19),
}, {
- .name = hsmmc,
- .devname= exynos4-sdhci.0,
+ .name = biu,
I have no idea why we change the clock name to 'biu' (bus interface
unit). Just let me know.
[...]
static struct clksrc_clk exynos5_clk_sclk_mmc0 = {
.clk= {
- .name = sclk_mmc,
- .devname= exynos4-sdhci.0,
+ .name = ciu,
Same as above.
[...]
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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
Re: [PATCH 0/3] Removal of obsolete s3c2410_* GPIO API
On 08/25/12 05:20, Sylwester Nawrocki wrote: This short patch series converts remaining users of the s3c24xx SoC specific gpiolib functions to the gpiolib API and finally removes all s3c2410_* functions from drivers/gpio/gpio-samsung.c. Sylwester Nawrocki (3): ARM: S3C24XX: Convert users of s3c2410_gpio_setpin to gpiolib API ARM: S3C24XX: Remove obsolete GPIO API declarations gpio-samsung: Remove now unused s3c2410_gpio* API arch/arm/mach-s3c24xx/mach-anubis.c |3 +- arch/arm/mach-s3c24xx/mach-jive.c | 12 ++-- arch/arm/mach-s3c24xx/mach-mini2440.c |4 +- arch/arm/mach-s3c24xx/mach-nexcoder.c | 22 +++--- arch/arm/mach-s3c24xx/mach-osiris.c |7 +- arch/arm/plat-samsung/include/plat/gpio-fns.h | 97 - drivers/gpio/gpio-samsung.c | 40 -- 7 files changed, 25 insertions(+), 160 deletions(-) Nice cleanup. Accordingly, we need to sort out the 'Documentation/arm/Samsung-S3C24XX/GPIO.txt' later? Linus, this series should be sent to upstream via both trees, samsung and gpio to avoid useless merge conflicts. How do you think? Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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
Re: [PATCH 0/3] Removal of obsolete s3c2410_* GPIO API
On Sat, Aug 25, 2012 at 5:20 AM, Sylwester Nawrocki sylvester.nawro...@gmail.com wrote: This short patch series converts remaining users of the s3c24xx SoC specific gpiolib functions to the gpiolib API and finally removes all s3c2410_* functions from drivers/gpio/gpio-samsung.c. I'm fine with this as long as the Samsung maintainer is, so Acked-by: Linus Walleij linus.wall...@linaro.org But I suspect this will be merged through the Samsung SoC tree? Yours, Linus Walleij -- 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
Re: [PATCH 0/3] Removal of obsolete s3c2410_* GPIO API
On Mon, Aug 27, 2012 at 4:33 PM, Kukjin Kim kgene@samsung.com wrote: Linus, this series should be sent to upstream via both trees, samsung and gpio to avoid useless merge conflicts. How do you think? Take it all in the Samsung tree. You just need my ACK, which you have. I don't have any big Samsung patches in my tree, just fixes that will go into the -rc:s anyway. Yours, Linus Walleij -- 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
Re: [PATCH] gpio: samsung: add devicetree init for s3c24xx arches
On 27 August 2012 13:31, Heiko Stübner he...@sntech.de wrote:
Hi Thomas,
thanks for your review:
Am Montag, 27. August 2012, 06:20:49 schrieb Thomas Abraham:
Hi Heiko,
On 26 August 2012 03:23, Heiko Stübner he...@sntech.de wrote:
Until now the Exynos-SoC was the only Samsung-SoC supporting the GPIOs
via the device tree. This patch implements dt-support for the
s3c24xx arches.
The controllers contain only 3 cells, as the underlying gpio controller
does not support controlling the drive strength on a gpio level.
Tested with the gpio-keys driver on a s3c2416 based machine.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
.../devicetree/bindings/gpio/gpio-samsung.txt | 38
drivers/gpio/gpio-samsung.c| 63
2 files changed, 101 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt index
5375625..ce6a7d4 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
@@ -39,3 +39,41 @@ Example:
#gpio-cells = 4;
gpio-controller;
};
+
+
+Samsung S3C24XX GPIO Controller
+
+Required properties:
+- compatible: Compatible property value should be
samsung,s3c24xx-gpio.
This is debatable, but I would choose to be specific here and use
samsing,s3c2416-gpio. For instance, SoC's in s3c24xx family have
differing value for pull none/down/up.
Hmmm, but the logic to drive the gpio controller is the same for all arches.
The only difference is the number to use for the different pull up/down
settings. So I think the samsung,s3c24xx-gpio is ok but the documentation
should simply reflect the different pull settings.
Ok.
+
+- reg: Physical base address of the controller and length of memory
mapped + region.
+
+- #gpio-cells: Should be 3. The syntax of the gpio specifier used by
client nodes + should be the following with values derived from the SoC
user manual. + [phandle of the gpio controller node]
+ [pin number within the gpio controller]
+ [mux function]
+ [flags and pull up/down]
+
+ Values for gpio specifier:
+ - Pin number: depending on the controller a number from 0 up to 15.
+ - Flags and Pull Up/Down: 0 - Pull Up/Down Disabled.
+1 - Pull Down Enabled.
+3 - Pull Up Enabled.
As per s3c2416 user manual, 2 is used for Pull Up and 3 is listed as
reserved value. Any particular reason to use 3 here for pull up and
not 2 as per the user manual?
Sorry, copy and paste error :-)
Ok.
+ Bit 16 (0x0001) - Input is active low.
+
+- gpio-controller: Specifies that the node is a gpio controller.
+- #address-cells: should be 1.
+- #size-cells: should be 1.
It would be informative to add information about the 'mux function'
cell here as well. Specifically, on how to handle the banks that have
an extended GPxSEL register that allow additional pin function
selection.
Will add a mux function description.
Until now I've never realised the existence of the GPxSEL registers, so thanks
for the pointer :-).
But is this used in the driver at all? All the setcfg/getcfg functions in
gpio-samsung.c only handle the GPxCON registers - I haven't found code to
handle the GPxSEL registers at all. So my guess is that this was never
implemented - or that I'm blind ;-) .
You are right, there is no code that is handling the GPxCON registers.
Thanks,
Thomas.
+
+Example:
+
+ gpa: gpio-controller@5600 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = samsung,s3c24xx-gpio;
+ reg = 0x5600 0x10;
+ #gpio-cells = 3;
+ gpio-controller;
+ };
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index a150d2e..80a2817 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -938,6 +938,67 @@ static void __init samsung_gpiolib_add(struct
samsung_gpio_chip *chip)
s3c_gpiolib_track(chip);
}
+#if defined(CONFIG_PLAT_S3C24XX) defined(CONFIG_OF)
+static int s3c24xx_gpio_xlate(struct gpio_chip *gc,
+ const struct of_phandle_args *gpiospec, u32
*flags) +{
+ unsigned int pin;
+
+ if (WARN_ON(gc-of_gpio_n_cells 3))
+ return -EINVAL;
+
+ if (WARN_ON(gpiospec-args_count gc-of_gpio_n_cells))
+ return -EINVAL;
+
+ if (gpiospec-args[0] gc-ngpio)
+ return -EINVAL;
+
+ pin = gc-base + gpiospec-args[0];
+
+ if (s3c_gpio_cfgpin(pin, S3C_GPIO_SFN(gpiospec-args[1])))
+ pr_warn(gpio_xlate: failed to set pin
Re: [PATCH v4 9/9] mmc: dw_mmc: add support for exynos specific implementation of dw-mshc
On 27 August 2012 14:28, Jaehoon Chung jh80.ch...@samsung.com wrote:
Hi Thomas,
+ gpio = of_get_named_gpio(slot_np, wp-gpios, 0);
+ if (gpio_is_valid(gpio)) {
+ if (devm_gpio_request(host-dev, gpio, dw-mci-wp))
+ dev_info(host-dev, gpio [%d] request failed\n,
+ gpio);
+ } else {
+ dev_info(host-dev, wp gpio not available);
+ host-pdata-quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
+ }
+
+ if (host-pdata-quirks DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
+ return 0;
+
+ gpio = of_get_named_gpio(slot_np, samsung,cd-pinmux-gpio, 0);
+ if (gpio_is_valid(gpio)) {
+ if (devm_gpio_request(host-dev, gpio, dw-mci-cd))
I'm not sure, but i saw mmc_gpio_request_cd() into
drivers/mmc/core/slot-gpio.c.
Can we use this? i think we can use them.
Just my opinion.
Thanks for letting me know about this, I was not aware of this.
Looking into this code, it is usable for controllers that use a gpio
(specified using cd-gpios property) as card-detect line. As you know,
the dw-mmc driver does not support this feature yet. In case of
exynos, the card-detect pin of the mmc slot is connected to the
card-detect pad of the dw-mmc controller using pinmux, which is not
considered as a gpio. Hence, mmc_gpio_request_cd() is not applicable
in this case.
Thanks,
Thomas.
Best Regards,
Jaehoon Chung
+ dev_err(host-dev, gpio [%d] request failed\n, gpio);
+ } else {
+ dev_info(host-dev, cd gpio not available);
+ }
+
+ return 0;
+}
+
+/* Exynos5250 controller specific capabilities */
+static unsigned long exynos5250_dwmmc_caps[4] = {
+ MMC_CAP_UHS_DDR50 | MMC_CAP_1_8V_DDR |
+ MMC_CAP_8_BIT_DATA | MMC_CAP_CMD23,
+ MMC_CAP_CMD23,
+ MMC_CAP_CMD23,
+ MMC_CAP_CMD23,
+};
+
+static struct dw_mci_drv_data exynos5250_drv_data = {
+ .caps = exynos5250_dwmmc_caps,
+ .init = dw_mci_exynos_priv_init,
+ .prepare_command= dw_mci_exynos_prepare_command,
+ .set_ios= dw_mci_exynos_set_ios,
+ .parse_dt = dw_mci_exynos_parse_dt,
+ .setup_bus = dw_mci_exynos_setup_bus,
+};
+
+static const struct of_device_id dw_mci_exynos_match[] = {
+ { .compatible = samsung,exynos5250-dw-mshc,
+ .data = (void *)exynos5250_drv_data, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, dw_mci_pltfm_match);
+
+int dw_mci_exynos_probe(struct platform_device *pdev)
+{
+ struct dw_mci_drv_data *drv_data;
+ const struct of_device_id *match;
+
+ match = of_match_node(dw_mci_exynos_match, pdev-dev.of_node);
+ drv_data = match-data;
+ return dw_mci_pltfm_register(pdev, drv_data);
+}
+
+static struct platform_driver dw_mci_exynos_pltfm_driver = {
+ .probe = dw_mci_exynos_probe,
+ .remove = __exit_p(dw_mci_pltfm_remove),
+ .driver = {
+ .name = dwmmc_exynos,
+ .of_match_table = of_match_ptr(dw_mci_exynos_match),
+ .pm = dw_mci_pltfm_pmops,
+ },
+};
+
+module_platform_driver(dw_mci_exynos_pltfm_driver);
+
+MODULE_DESCRIPTION(Samsung Specific DW-MSHC Driver Extension);
+MODULE_AUTHOR(Thomas Abraham thomas...@samsung.com);
+MODULE_LICENSE(GPL v2);
+MODULE_ALIAS(platform:dwmmc-exynos);
--
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
Re: [PATCH v4 0/9] mmc: dw_mmc: add support for device tree based instantiation
On 27 August 2012 15:01, Will Newton will.new...@gmail.com wrote: On Sun, Aug 26, 2012 at 12:51 PM, Thomas Abraham thomas.abra...@linaro.org wrote: This is the fourth version of the patch series that adds device tree support for Synopsis Designware Mobile Storage Host Controller. In this version, the significant change is the spliting of Exynos specific code into a seperate file, as suggested by Seungwon Jeon tgih@samsung.com. Spliting the Exynos specific code into a seperate file did infact keeps the core driver code clean, which otherwise was littered with Exynos specific code. I hope the changes look sane, though. This has been tested only on smdk5250 board. Thomas Abraham (9): mmc: dw_mmc: convert copy of struct device in struct dw_mci to a reference mmc: dw_mmc: Use devm_* functions in dw_mmc platform driver mmc: dw_mmc: allow probe to succeed even if one slot is initialized mmc: dw_mmc: lookup for optional biu and ciu clocks mmc: dw_mmc: add quirk to indicate missing write protect line mmc: dw_mmc: add device tree support mmc: dw_mmc: prepare functions in dw_mmc-pltfm for reuse mmc: dw_mmc: add support for implementation specific callbacks mmc: dw_mmc: add support for exynos specific implementation of dw-mshc .../devicetree/bindings/mmc/exynos-dw-mshc.txt | 79 ++ .../devicetree/bindings/mmc/synposis-dw-mshc.txt | 90 ++ drivers/mmc/host/Kconfig |9 + drivers/mmc/host/Makefile |3 +- drivers/mmc/host/dw_mmc-exynos.c | 247 + drivers/mmc/host/dw_mmc-pci.c |2 +- drivers/mmc/host/dw_mmc-pltfm.c| 62 +++-- drivers/mmc/host/dw_mmc-pltfm.h| 20 ++ drivers/mmc/host/dw_mmc.c | 287 drivers/mmc/host/dw_mmc.h | 22 ++ include/linux/mmc/dw_mmc.h | 13 +- 11 files changed, 757 insertions(+), 77 deletions(-) create mode 100644 Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt create mode 100644 Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt create mode 100644 drivers/mmc/host/dw_mmc-exynos.c create mode 100644 drivers/mmc/host/dw_mmc-pltfm.h This series looks good to me, although I am not familiar enough with the device tree stuff to review it in a meaningful way. Acked-by: Will Newton will.new...@imgtec.com Note that the platform driver changes will conflict with Jaehoon Chung's patch to fix a section mismatch in that file. Have you tried building this as a module and with section mismatch debugging to make sure the new code does not add any mismatches? Thanks Will for reviewing this patch series. I tried building dw-mmc, dw-mmc-pltfm and dw-mmc-exynos as modules with section mismatch debugging enabled, and there were no warnings. But, I did find a problem with the Kconfig entry I made for dw-mmc-exynos file, instead of 'bool', I should have used 'tristate'. I will fix this and other comments and repost. Thanks, Thomas. -- 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
Re: [PATCH v4 9/9] mmc: dw_mmc: add support for exynos specific implementation of dw-mshc
Hi Thomas,
On 08/28/2012 01:48 PM, Thomas Abraham wrote:
On 27 August 2012 14:28, Jaehoon Chung jh80.ch...@samsung.com wrote:
Hi Thomas,
+ gpio = of_get_named_gpio(slot_np, wp-gpios, 0);
+ if (gpio_is_valid(gpio)) {
+ if (devm_gpio_request(host-dev, gpio, dw-mci-wp))
+ dev_info(host-dev, gpio [%d] request failed\n,
+ gpio);
+ } else {
+ dev_info(host-dev, wp gpio not available);
+ host-pdata-quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
+ }
+
+ if (host-pdata-quirks DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
+ return 0;
+
+ gpio = of_get_named_gpio(slot_np, samsung,cd-pinmux-gpio, 0);
+ if (gpio_is_valid(gpio)) {
+ if (devm_gpio_request(host-dev, gpio, dw-mci-cd))
I'm not sure, but i saw mmc_gpio_request_cd() into
drivers/mmc/core/slot-gpio.c.
Can we use this? i think we can use them.
Just my opinion.
Thanks for letting me know about this, I was not aware of this.
Looking into this code, it is usable for controllers that use a gpio
(specified using cd-gpios property) as card-detect line. As you know,
the dw-mmc driver does not support this feature yet. In case of
exynos, the card-detect pin of the mmc slot is connected to the
card-detect pad of the dw-mmc controller using pinmux, which is not
considered as a gpio. Hence, mmc_gpio_request_cd() is not applicable
in this case.
But In case of external card-detect-pin, we can use the mmc_gpio_request_cd().
Best Regards,
Jaehoon Chung
Thanks,
Thomas.
Best Regards,
Jaehoon Chung
+ dev_err(host-dev, gpio [%d] request failed\n,
gpio);
+ } else {
+ dev_info(host-dev, cd gpio not available);
+ }
+
+ return 0;
+}
+
+/* Exynos5250 controller specific capabilities */
+static unsigned long exynos5250_dwmmc_caps[4] = {
+ MMC_CAP_UHS_DDR50 | MMC_CAP_1_8V_DDR |
+ MMC_CAP_8_BIT_DATA | MMC_CAP_CMD23,
+ MMC_CAP_CMD23,
+ MMC_CAP_CMD23,
+ MMC_CAP_CMD23,
+};
+
+static struct dw_mci_drv_data exynos5250_drv_data = {
+ .caps = exynos5250_dwmmc_caps,
+ .init = dw_mci_exynos_priv_init,
+ .prepare_command= dw_mci_exynos_prepare_command,
+ .set_ios= dw_mci_exynos_set_ios,
+ .parse_dt = dw_mci_exynos_parse_dt,
+ .setup_bus = dw_mci_exynos_setup_bus,
+};
+
+static const struct of_device_id dw_mci_exynos_match[] = {
+ { .compatible = samsung,exynos5250-dw-mshc,
+ .data = (void *)exynos5250_drv_data, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, dw_mci_pltfm_match);
+
+int dw_mci_exynos_probe(struct platform_device *pdev)
+{
+ struct dw_mci_drv_data *drv_data;
+ const struct of_device_id *match;
+
+ match = of_match_node(dw_mci_exynos_match, pdev-dev.of_node);
+ drv_data = match-data;
+ return dw_mci_pltfm_register(pdev, drv_data);
+}
+
+static struct platform_driver dw_mci_exynos_pltfm_driver = {
+ .probe = dw_mci_exynos_probe,
+ .remove = __exit_p(dw_mci_pltfm_remove),
+ .driver = {
+ .name = dwmmc_exynos,
+ .of_match_table = of_match_ptr(dw_mci_exynos_match),
+ .pm = dw_mci_pltfm_pmops,
+ },
+};
+
+module_platform_driver(dw_mci_exynos_pltfm_driver);
+
+MODULE_DESCRIPTION(Samsung Specific DW-MSHC Driver Extension);
+MODULE_AUTHOR(Thomas Abraham thomas...@samsung.com);
+MODULE_LICENSE(GPL v2);
+MODULE_ALIAS(platform:dwmmc-exynos);
--
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
Re: [PATCH v3 1/3] ARM: Samsung: Add support for MSHC controller clocks
On 28 August 2012 04:45, Kukjin Kim kgene@samsung.com wrote:
On 08/26/12 04:59, Thomas Abraham wrote:
Add clock instances for bus interface unit clock and card interface unit
clock of the all four MSHC controller instances.
Signed-off-by: Abhilash Kesavana.kesa...@samsung.com
Signed-off-by: Thomas Abrahamthomas.abra...@linaro.org
---
arch/arm/mach-exynos/clock-exynos5.c | 45
--
1 files changed, 16 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index 3b00e29..16d8bef 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -564,35 +564,30 @@ static struct clk exynos5_init_clocks_off[] = {
.enable = exynos5_clk_ip_peris_ctrl,
.ctrlbit= (1 19),
}, {
- .name = hsmmc,
- .devname= exynos4-sdhci.0,
+ .name = biu,
I have no idea why we change the clock name to 'biu' (bus interface unit).
Just let me know.
The dw-mmc controller requires two clocks - bus interface unit and
card interface unit clock. Since this controller driver can be used on
platforms other than exynos, the name of the clock has to be generic.
Hence the name of the clocks used are biu and ciu as the per the
dw-mmc data sheet.
[...]
static struct clksrc_clk exynos5_clk_sclk_mmc0 = {
.clk= {
- .name = sclk_mmc,
- .devname= exynos4-sdhci.0,
+ .name = ciu,
Same as above.
Thanks,
Thomas.
--
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
Re: [PATCH v3 2/3] ARM: Exynos5: Add AUXDATA support for MSHC controllers
On 28 August 2012 04:41, Kukjin Kim kgene@samsung.com wrote:
On 08/26/12 04:59, Thomas Abraham wrote:
Add entries if MSHC controllers in AUXDATA table for correct device name
initialization.
Signed-off-by: Abhilash Kesavana.kesa...@samsung.com
Signed-off-by: Thomas Abrahamthomas.abra...@linaro.org
---
arch/arm/mach-exynos/include/mach/map.h |1 +
arch/arm/mach-exynos/mach-exynos5-dt.c |8
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 9d1f3ac..5b0ee41 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -172,6 +172,7 @@
#define EXYNOS4_PA_HSMMC(x) (0x1251 + ((x) * 0x1))
#define EXYNOS4_PA_DWMCI 0x1255
+#define EXYNOS5_PA_DWMCI(x)(0x1220 + ((x) * 0x1))
Just, how about EXYNOS5_PA_DWMMC0, EXYNOS5_PA_DWMMC1, ... EXYNOS_PA_DWMMC3?
Ok.
And if the addresses are different on other EXYNOS5 SoC, how do we handle it
for auxdata?
I hope that does not happen. So do you suggest that I change this to
EYNOS5250_PA_DWMMC0 ?
#define EXYNOS4_PA_HSOTG 0x1248
#define EXYNOS4_PA_USB_HSPHY 0x125B
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index ef770bc..4257cc1 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -47,6 +47,14 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[] __initconst = {
s3c2440-i2c.0, NULL),
OF_DEV_AUXDATA(samsung,s3c2440-i2c, EXYNOS5_PA_IIC(1),
s3c2440-i2c.1, NULL),
+ OF_DEV_AUXDATA(samsung,exynos5250-dw-mshc, EXYNOS5_PA_DWMCI(0),
As I commented, how about just 'samsung,dw-mmc'? but I'm not sure.
The dw-mmc controllers on Exynos 4210/4412/5250 have incremental
features. So different compatible strings are required to identify the
type of the controller.
Thanks for reviewing this patch series.
Regards,
Thomas.
--
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
Re: [PATCH v3 3/3] ARM: dts: Add nodes for dw_mmc controllers for Samsung Exynos5250 platforms
On 28 August 2012 04:16, Kukjin Kim kgene@samsung.com wrote:
On 08/26/12 04:59, Thomas Abraham wrote:
Add device nodes for the four instances of dw_mmc controllers in
Exynos5250
and enable instance 0 and 2 for the smdk5250 board.
Signed-off-by: Thomas Abrahamthomas.abra...@linaro.org
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 57
-
arch/arm/boot/dts/exynos5250.dtsi | 32
2 files changed, 88 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 8a5e348..6dc9faf 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -16,12 +16,19 @@
model = SAMSUNG SMDK5250 board based on EXYNOS5250;
compatible = samsung,smdk5250, samsung,exynos5250;
+ aliases {
+ mshc0 =mshc_0;
+ mshc1 =mshc_1;
+ mshc2 =mshc_2;
+ mshc3 =mshc_3;
+ };
+
memory {
reg =0x4000 0x8000;
};
chosen {
- bootargs = root=/dev/ram0 rw ramdisk=8192
console=ttySAC1,115200;
+ bootargs = root=/dev/ram0 rw ramdisk=8192
initrd=0x4100,8M console=ttySAC2,115200 init=/linuxrc;
Yes, we need to sort out the 'bootargs' for using uart2 as a console, but
you know, this should be separated :-)
Sorry, that was never intended to be in this patch. My mistake.
};
i2c@12C6 {
@@ -72,6 +79,54 @@
status = disabled;
};
+ mshc_0: dwmmc0@1220 {
How about to keep the consistent naming? dwmmc or dw_mmc? I think, 'dw_mmc'
makes more sense?
Ok.
+ num-slots =1;
+ supports-highspeed;
+ broken-cd;
+ fifo-depth =0x80;
+ card-detect-delay =200;
+ samsung,dw-mshc-sdr-timing =2 3 3;
+ samsung,dw-mshc-ddr-timing =1 2 3;
We need to think again the name of dw-mshc-sdr-timing, dw-mshc-ddr-timing?
Synopsis calls this controller Mobile Storage Host Controller (MSHC)
in their online data sheets. Hence, all the bindings (which are used
on non-samsung platforms as well) follow the this name. For any
Samsung specific code for this controller, we are free to choose any
name.
[...]
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 004aaa8..f69e389 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -182,6 +182,38 @@
#size-cells =0;
};
+ dwmmc0@1220 {
+ compatible = samsung,exynos5250-dw-mshc;
I'm not sure, 'exynos5250-dw-mshc' is right here. Because it is just dw_mmc
controller on exynos5250. So...hmm...
There are differences in the implementation of the dw-mmc controller
in Exynos SoC's. So it has to be exynos5250-dw-mshc.
Thanks,
Thomas.
--
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
Re: [PATCH v4 9/9] mmc: dw_mmc: add support for exynos specific implementation of dw-mshc
On 28 August 2012 10:25, Jaehoon Chung jh80.ch...@samsung.com wrote:
Hi Thomas,
On 08/28/2012 01:48 PM, Thomas Abraham wrote:
On 27 August 2012 14:28, Jaehoon Chung jh80.ch...@samsung.com wrote:
Hi Thomas,
+ gpio = of_get_named_gpio(slot_np, wp-gpios, 0);
+ if (gpio_is_valid(gpio)) {
+ if (devm_gpio_request(host-dev, gpio, dw-mci-wp))
+ dev_info(host-dev, gpio [%d] request failed\n,
+ gpio);
+ } else {
+ dev_info(host-dev, wp gpio not available);
+ host-pdata-quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
+ }
+
+ if (host-pdata-quirks DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
+ return 0;
+
+ gpio = of_get_named_gpio(slot_np, samsung,cd-pinmux-gpio, 0);
+ if (gpio_is_valid(gpio)) {
+ if (devm_gpio_request(host-dev, gpio, dw-mci-cd))
I'm not sure, but i saw mmc_gpio_request_cd() into
drivers/mmc/core/slot-gpio.c.
Can we use this? i think we can use them.
Just my opinion.
Thanks for letting me know about this, I was not aware of this.
Looking into this code, it is usable for controllers that use a gpio
(specified using cd-gpios property) as card-detect line. As you know,
the dw-mmc driver does not support this feature yet. In case of
exynos, the card-detect pin of the mmc slot is connected to the
card-detect pad of the dw-mmc controller using pinmux, which is not
considered as a gpio. Hence, mmc_gpio_request_cd() is not applicable
in this case.
But In case of external card-detect-pin, we can use the mmc_gpio_request_cd().
Yes, we can use. But the current dw-mmc controller driver does not
support this feature yet. The existing driver considers that (a)
card-detect line is connected to the card-detect pad of the controller
or (b) it is broken. For Exynos5250, it is case (a). There is no
support for using a gpio as an card-detect line.
Thanks,
Thomas.
--
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
Re: [PATCH v4 9/9] mmc: dw_mmc: add support for exynos specific implementation of dw-mshc
On 28 August 2012 10:40, Thomas Abraham thomas.abra...@linaro.org wrote:
On 28 August 2012 10:25, Jaehoon Chung jh80.ch...@samsung.com wrote:
Hi Thomas,
On 08/28/2012 01:48 PM, Thomas Abraham wrote:
On 27 August 2012 14:28, Jaehoon Chung jh80.ch...@samsung.com wrote:
Hi Thomas,
+ gpio = of_get_named_gpio(slot_np, wp-gpios, 0);
+ if (gpio_is_valid(gpio)) {
+ if (devm_gpio_request(host-dev, gpio, dw-mci-wp))
+ dev_info(host-dev, gpio [%d] request failed\n,
+ gpio);
+ } else {
+ dev_info(host-dev, wp gpio not available);
+ host-pdata-quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
+ }
+
+ if (host-pdata-quirks DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
+ return 0;
+
+ gpio = of_get_named_gpio(slot_np, samsung,cd-pinmux-gpio, 0);
+ if (gpio_is_valid(gpio)) {
+ if (devm_gpio_request(host-dev, gpio, dw-mci-cd))
I'm not sure, but i saw mmc_gpio_request_cd() into
drivers/mmc/core/slot-gpio.c.
Can we use this? i think we can use them.
Just my opinion.
Thanks for letting me know about this, I was not aware of this.
Looking into this code, it is usable for controllers that use a gpio
(specified using cd-gpios property) as card-detect line. As you know,
the dw-mmc driver does not support this feature yet. In case of
exynos, the card-detect pin of the mmc slot is connected to the
card-detect pad of the dw-mmc controller using pinmux, which is not
considered as a gpio. Hence, mmc_gpio_request_cd() is not applicable
in this case.
But In case of external card-detect-pin, we can use the
mmc_gpio_request_cd().
Yes, we can use. But the current dw-mmc controller driver does not
support this feature yet. The existing driver considers that (a)
card-detect line is connected to the card-detect pad of the controller
or (b) it is broken. For Exynos5250, it is case (a). There is no
Sorry, I meant smdk5250, not Exynos5250.
support for using a gpio as an card-detect line.
Thanks,
Thomas.
--
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
Re: [PATCH v4 9/9] mmc: dw_mmc: add support for exynos specific implementation of dw-mshc
On 08/28/2012 02:10 PM, Thomas Abraham wrote:
On 28 August 2012 10:40, Thomas Abraham thomas.abra...@linaro.org wrote:
On 28 August 2012 10:25, Jaehoon Chung jh80.ch...@samsung.com wrote:
Hi Thomas,
On 08/28/2012 01:48 PM, Thomas Abraham wrote:
On 27 August 2012 14:28, Jaehoon Chung jh80.ch...@samsung.com wrote:
Hi Thomas,
+ gpio = of_get_named_gpio(slot_np, wp-gpios, 0);
+ if (gpio_is_valid(gpio)) {
+ if (devm_gpio_request(host-dev, gpio, dw-mci-wp))
+ dev_info(host-dev, gpio [%d] request failed\n,
+ gpio);
+ } else {
+ dev_info(host-dev, wp gpio not available);
+ host-pdata-quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
+ }
+
+ if (host-pdata-quirks DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
+ return 0;
+
+ gpio = of_get_named_gpio(slot_np, samsung,cd-pinmux-gpio, 0);
+ if (gpio_is_valid(gpio)) {
+ if (devm_gpio_request(host-dev, gpio, dw-mci-cd))
I'm not sure, but i saw mmc_gpio_request_cd() into
drivers/mmc/core/slot-gpio.c.
Can we use this? i think we can use them.
Just my opinion.
Thanks for letting me know about this, I was not aware of this.
Looking into this code, it is usable for controllers that use a gpio
(specified using cd-gpios property) as card-detect line. As you know,
the dw-mmc driver does not support this feature yet. In case of
exynos, the card-detect pin of the mmc slot is connected to the
card-detect pad of the dw-mmc controller using pinmux, which is not
considered as a gpio. Hence, mmc_gpio_request_cd() is not applicable
in this case.
But In case of external card-detect-pin, we can use the
mmc_gpio_request_cd().
Yes, we can use. But the current dw-mmc controller driver does not
support this feature yet. The existing driver considers that (a)
card-detect line is connected to the card-detect pad of the controller
or (b) it is broken. For Exynos5250, it is case (a). There is no
Sorry, I meant smdk5250, not Exynos5250.
Already i tested with my exynos5 board.
If you want, i will share the patch.
Best Regards,
Jaehoon Chung
support for using a gpio as an card-detect line.
Thanks,
Thomas.
--
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-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 9/9] mmc: dw_mmc: add support for exynos specific implementation of dw-mshc
On 28 August 2012 10:46, Jaehoon Chung jh80.ch...@samsung.com wrote:
On 08/28/2012 02:10 PM, Thomas Abraham wrote:
On 28 August 2012 10:40, Thomas Abraham thomas.abra...@linaro.org wrote:
On 28 August 2012 10:25, Jaehoon Chung jh80.ch...@samsung.com wrote:
Hi Thomas,
On 08/28/2012 01:48 PM, Thomas Abraham wrote:
On 27 August 2012 14:28, Jaehoon Chung jh80.ch...@samsung.com wrote:
Hi Thomas,
+ gpio = of_get_named_gpio(slot_np, wp-gpios, 0);
+ if (gpio_is_valid(gpio)) {
+ if (devm_gpio_request(host-dev, gpio, dw-mci-wp))
+ dev_info(host-dev, gpio [%d] request failed\n,
+ gpio);
+ } else {
+ dev_info(host-dev, wp gpio not available);
+ host-pdata-quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
+ }
+
+ if (host-pdata-quirks DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
+ return 0;
+
+ gpio = of_get_named_gpio(slot_np, samsung,cd-pinmux-gpio, 0);
+ if (gpio_is_valid(gpio)) {
+ if (devm_gpio_request(host-dev, gpio, dw-mci-cd))
I'm not sure, but i saw mmc_gpio_request_cd() into
drivers/mmc/core/slot-gpio.c.
Can we use this? i think we can use them.
Just my opinion.
Thanks for letting me know about this, I was not aware of this.
Looking into this code, it is usable for controllers that use a gpio
(specified using cd-gpios property) as card-detect line. As you know,
the dw-mmc driver does not support this feature yet. In case of
exynos, the card-detect pin of the mmc slot is connected to the
card-detect pad of the dw-mmc controller using pinmux, which is not
considered as a gpio. Hence, mmc_gpio_request_cd() is not applicable
in this case.
But In case of external card-detect-pin, we can use the
mmc_gpio_request_cd().
Yes, we can use. But the current dw-mmc controller driver does not
support this feature yet. The existing driver considers that (a)
card-detect line is connected to the card-detect pad of the controller
or (b) it is broken. For Exynos5250, it is case (a). There is no
Sorry, I meant smdk5250, not Exynos5250.
Already i tested with my exynos5 board.
If you want, i will share the patch.
But did you use samsung,cd-pinmux-gpio binding or cd-gpios binding
for specifying the card-detect line. I think, for your board, you have
to use cd-gpios. But this patch series does not add support for
cd-gpios.
Sure, I will like to have a look at your patch and understand more.
Thanks,
Thomas.
--
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
Re: [PATCH v2 1/4] pinctrl: add samsung pinctrl and gpiolib driver
On 28 August 2012 04:52, Linus Walleij linus.wall...@linaro.org wrote:
On Tue, Aug 21, 2012 at 9:22 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
[...]
+/* list of all possible config options supported */
+struct pin_config {
+ char*prop_cfg;
+ unsigned intcfg_type;
+} pcfgs[] = {
+ { samsung,pin-pud, PINCFG_TYPE_PUD },
+ { samsung,pin-drv, PINCFG_TYPE_DRV },
+ { samsung,pin-pud-pdn, PINCFG_TYPE_CON_PND },
+ { samsung,pin-drv-pdn, PINCFG_TYPE_PUD_PND },
+};
Hm it looks very much like this controller could make use of
the generic pinconf library, but it's not mandatory so just a suggestion.
Ok. The last two entries in the above table are Samsung specific and
not covered by generic-pinconf. So, I am not sure if it can be added
to generic-pinconf.
What is so Samsung-specific about them?
If you tell us the electrical property of setting them we can figure out
if they should be generic or not...
The PINCFG_TYPE_CON_PND and PINCFG_TYPE_PUD_PND are mux function and
pull up/down settings that are automatically applied to the pin in
powert-down mode. It is same as the usual mux function and pull
up/down settings, but just that it is applied at suspend.
[...]
OK whatever... looking formward to next iteration!
I have posted the updated version of this patch series based on your
comments (https://lkml.org/lkml/2012/8/23/183).
The only pending comment to be addressed at this point is about the
use of generic-pinconf as mentioned in the comment above. If
PINCFG_TYPE_CON_PND and PINCFG_TYPE_PUD_PND is available in
generic-pinconf, I wil switch to using generic-pinconf. Will that
qualify this Samsung pinctrl driver to be merged into your -devel
branch?
Thanks,
Thomas.
--
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
