[PATCH V2] drm/exynos: Fix multiplatform breakage for ipp/gsc
There is no need to include "plat/map-base.h" in ipp driver. Remove this and enable this driver for multi-platform. However gsc driver is not multiplatform compliant yet, so make the compilation conditional upon !ARCH_MULTIPLATFORM. Signed-off-by: Tushar Behera --- Changes for V2: * Made compilation of exynos_drm_gsc.c conditional on !ARCH_MULTIPLATFORM. drivers/gpu/drm/exynos/Kconfig |4 ++-- drivers/gpu/drm/exynos/exynos_drm_ipp.c |1 - 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index f227f54..6e1a1a2 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -51,7 +51,7 @@ config DRM_EXYNOS_G2D config DRM_EXYNOS_IPP bool "Exynos DRM IPP" - depends on DRM_EXYNOS && !ARCH_MULTIPLATFORM + depends on DRM_EXYNOS help Choose this option if you want to use IPP feature for DRM. @@ -69,6 +69,6 @@ config DRM_EXYNOS_ROTATOR config DRM_EXYNOS_GSC bool "Exynos DRM GSC" - depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 + depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 && !ARCH_MULTIPLATFORM help Choose this option if you want to use Exynos GSC for DRM. diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c b/drivers/gpu/drm/exynos/exynos_drm_ipp.c index d519a4e..eefb429 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c @@ -16,7 +16,6 @@ #include #include #include -#include #include #include -- 1.7.9.5 -- 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
[PATCH] tty: Fallback to use dynamic major number
In a multi-platform scenario, the hard-coded major/minor numbers in
serial drivers may conflict with each other. A typical scenario is
observed with amba-pl011 and samsung-uart drivers, both of these
drivers use same set of major/minor numbers. If both of these drivers
are enabled, probe of samsung-uart driver fails because the desired
node is busy.
The issue is fixed by adding a fallback in driver core, so that we can
use dynamic major number in case device node allocation fails for
hard-coded major/minor number.
Signed-off-by: Tushar Behera
---
Hi Greg,
This is my second attempt at getting this fixed. Let me know if you are
okay with this.
Initial approach to fix this problem was by forcing samsung-uart driver
to use dynamic major number, but it was rejected [1] because of possible
user-space breakage. Current approach falls back to dynamic major
number as a fallback in case of failure.
[1] https://lkml.org/lkml/2013/12/27/2
drivers/tty/tty_io.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index c74a00a..0c692be 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -3341,6 +3341,22 @@ int tty_register_driver(struct tty_driver *driver)
dev_t dev;
struct device *d;
+ if (driver->major) {
+ dev = MKDEV(driver->major, driver->minor_start);
+ error = register_chrdev_region(dev, driver->num, driver->name);
+ /* In case of error, fall back to dynamic allocation */
+ if (error < 0) {
+ pr_warn("Default device node (%d:%d) for %s is busy,
using dynamic node\n",
+ driver->major, driver->minor_start,
+ driver->name);
+ driver->major = 0;
+ }
+ }
+
+ /*
+* Don't replace the following check with an else to above if statement,
+* as it may also be called as a fallback.
+*/
if (!driver->major) {
error = alloc_chrdev_region(&dev, driver->minor_start,
driver->num, driver->name);
@@ -3348,9 +3364,6 @@ int tty_register_driver(struct tty_driver *driver)
driver->major = MAJOR(dev);
driver->minor_start = MINOR(dev);
}
- } else {
- dev = MKDEV(driver->major, driver->minor_start);
- error = register_chrdev_region(dev, driver->num, driver->name);
}
if (error < 0)
goto err;
--
1.7.9.5
--
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] drm/exynos: Fix multiplatform breakage for ipp
On 16 January 2014 10:33, Sachin Kamat wrote: > Hi Tushar, > > On 15 January 2014 17:27, Tushar Behera wrote: >> There is no need to include "plat/map-base.h" in ipp driver. Remove >> this and enable this driver for multi-platform. >> >> Signed-off-by: Tushar Behera > > drivers/gpu/drm/exynos/exynos_drm_gsc.c also has this header file included. > If this file is needed there, then you may have to add !ARCH_MULTIPLATFORM > as its dependency. > Yes, true. There are still some users for this header file within exynos_drm_gsc.c, so we need to make the compilation conditional. I will add that and resend the patch. > -- > With warm regards, > Sachin Thanks. -- Tushar Behera -- 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] drm/exynos: Fix multiplatform breakage for ipp
Hi Tushar, On 15 January 2014 17:27, Tushar Behera wrote: > There is no need to include "plat/map-base.h" in ipp driver. Remove > this and enable this driver for multi-platform. > > Signed-off-by: Tushar Behera drivers/gpu/drm/exynos/exynos_drm_gsc.c also has this header file included. If this file is needed there, then you may have to add !ARCH_MULTIPLATFORM as its dependency. -- With warm regards, Sachin -- 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 1/1] ARM: S3C24XX: Move rtc-core.h from plat to mach
Am Montag, 30. Dezember 2013, 16:10:08 schrieb Sachin Kamat:
> plat/rtc-core.h is only referenced from mach-s3c24xx. Hence
> move it there to de-populate the plat directory. While at it
> also do some cleanup of the header file.
>
> Signed-off-by: Sachin Kamat
> Cc: Heiko Stuebner
late, but as the patch is not merged yet:
Acked-by: Heiko Stuebner
> ---
> .../plat => mach-s3c24xx/include/mach}/rtc-core.h | 13 ++---
> arch/arm/mach-s3c24xx/s3c2416.c|2 +-
> arch/arm/mach-s3c24xx/s3c2443.c|2 +-
> 3 files changed, 8 insertions(+), 9 deletions(-)
> rename arch/arm/{plat-samsung/include/plat =>
> mach-s3c24xx/include/mach}/rtc-core.h (69%)
>
> diff --git a/arch/arm/plat-samsung/include/plat/rtc-core.h
> b/arch/arm/mach-s3c24xx/include/mach/rtc-core.h similarity index 69%
> rename from arch/arm/plat-samsung/include/plat/rtc-core.h
> rename to arch/arm/mach-s3c24xx/include/mach/rtc-core.h
> index 7b542f7b7938..4d5f5768f700 100644
> --- a/arch/arm/plat-samsung/include/plat/rtc-core.h
> +++ b/arch/arm/mach-s3c24xx/include/mach/rtc-core.h
> @@ -1,5 +1,4 @@
> -/* linux/arch/arm/plat-samsung/include/plat/rtc-core.h
> - *
> +/*
> * Copyright (c) 2011 Heiko Stuebner
> *
> * Samsung RTC Controller core functions
> @@ -9,19 +8,19 @@
> * published by the Free Software Foundation.
> */
>
> -#ifndef __ASM_PLAT_RTC_CORE_H
> -#define __ASM_PLAT_RTC_CORE_H __FILE__
> +#ifndef __RTC_CORE_H
> +#define __RTC_CORE_H __FILE__
>
> /* These functions are only for use with the core support code, such as
> * the cpu specific initialisation code
> */
>
> +extern struct platform_device s3c_device_rtc;
> +
> /* re-define device name depending on support. */
> static inline void s3c_rtc_setname(char *name)
> {
> -#if defined(CONFIG_S3C_DEV_RTC) || defined(CONFIG_PLAT_S3C24XX)
> s3c_device_rtc.name = name;
> -#endif
> }
>
> -#endif /* __ASM_PLAT_RTC_CORE_H */
> +#endif /* __RTC_CORE_H */
> diff --git a/arch/arm/mach-s3c24xx/s3c2416.c
> b/arch/arm/mach-s3c24xx/s3c2416.c index cb77880029f7..a0b787505c02 100644
> --- a/arch/arm/mach-s3c24xx/s3c2416.c
> +++ b/arch/arm/mach-s3c24xx/s3c2416.c
> @@ -48,6 +48,7 @@
> #include
>
> #include
> +#include
>
> #include
> #include
> @@ -61,7 +62,6 @@
> #include
> #include
> #include
> -#include
> #include
>
> #include "common.h"
> diff --git a/arch/arm/mach-s3c24xx/s3c2443.c
> b/arch/arm/mach-s3c24xx/s3c2443.c index faa1086924c4..4af858457b2f 100644
> --- a/arch/arm/mach-s3c24xx/s3c2443.c
> +++ b/arch/arm/mach-s3c24xx/s3c2443.c
> @@ -34,6 +34,7 @@
> #include
>
> #include
> +#include
>
> #include
> #include
> @@ -43,7 +44,6 @@
> #include
> #include
> #include
> -#include
> #include
>
> static struct map_desc s3c2443_iodesc[] __initdata = {
--
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 4/5] arm: omap3: twl: use the new lookup method with usb phy
Hi, On Tuesday 14 January 2014 08:08 PM, Heikki Krogerus wrote: > On Tue, Jan 07, 2014 at 06:31:52PM +0530, Kishon Vijay Abraham I wrote: >>> In any case, having two device names to deal with does not add any >>> more risk. These associations should always be made in the place where >>> the phy device is created so you will always know it's device name. >> >> huh.. we should also know the 'controller' device name while defining these >> associations and in some cases the controller device and phy device are >> created >> in entirely different places. > > If you don't want to use the controller device name to do the > matching, we can use the con_id string as well. I believe the lookup > method I use in this set just needs a small change. The point I'm trying to make is that we won't 'always' know the device names in advance. Btw how are you planning to differentiate between multiple controllers of the same type with con_id? Maybe I'm missing the actual intention of this patch. Do you face problem if the PHY's have to know about it's consumers in ACPI? > > Is that OK with you? > > >>> Normally the platform code creates these associations in the same >>> place it creates the platform devices, so you definitely know what the >>> device names will be. >>> >>> In this case it's actually created in drivers/mfd/twl-core.c, so I do >>> need to update this and move the lookup table there. We can still >>> deliver the user name as platform data, though I believe it's always >>> "musb". Maybe we could actually skip that and just hard code the name? >> >> I would rather leave the way it is modelled now. > > Do you mean, leave it in the platform code? Why? We would reduce the > platform code by moving it to the mfd driver. Or did I misunderstood > something? In this case, the lookup table will be used only for non-dt boot so don't see much use in moving to mfd driver. I meant if the new method is not solving any problem then I would prefer the way it is modelled now where the PHY's know about it's consumers. Btw where does device gets created in ACPI boot? Cheers Kishon -- 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 2/5] phy: add support for indexed lookup
Hi Heikki, On Tuesday 14 January 2014 07:53 PM, Heikki Krogerus wrote: > Hi Kishon, > > And happy new year.. Happy new year :-) > > On Tue, Jan 07, 2014 at 07:10:36PM +0530, Kishon Vijay Abraham I wrote: > /** > - * phy_get() - lookup and obtain a reference to a phy. > + * phy_get_index() - obtain a phy based on index NAK. It still takes a 'char' argument and the name is misleading. Btw are you replacing phy_get() or adding a new API in addition to phy_get()? >>> >>> Additional API. The phy_get() would in practice act as a wrapper after >> >> In this patch it looks like you've replaced phy_get(). >>> this. It could actually be just a #define macro in the include file. >>> The function naming I just copied straight from gpiolib.c. I did not >>> have the imagination for anything fancier. >>> >>> I would like to be able to use some function like phy_get_index() and >>> be able to deliver it both the name and the index. With DT you guys >>> will always be able to use the name (and the string will always >>> supersede the index if we do it like this), but with ACPI, and possibly >>> the platform lookup tables, the index can be used... >> >> I think in that case, we should drop the 'string' from phy_get_index since we >> have the other API to handle that? I don't know about ACPI, but is it not >> possible to use strings with ACPI? > > No unfortunately. We just have what the ACPI tables provide. The PHYs > would be "child" device entries under the controller and we can only > get handle to them based on the index. > > I think I'll skip this patch from this set. Let's wait until we have > an actual ACPI DSDT describing some PHYs. yeah.. sure. Cheers Kishon -- 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: S3C[24|64]xx: move includes back under scope
On Wednesday 15 January 2014, Linus Walleij wrote: > When I look at it, the issue also exist in e.g. > drivers/gpio/gpio-samsung.c which can be compiled > (like for allyesconfig) when PLAT_SAMSUNG is set. > > And it is also set to y for ARCH_EXYNOS... which > doesn't have any custom GPIO header. So this would > involve something like creating an empty > for Exynos which doesn't > seem like the right thing to do. Ah, right. I looked at this before, but I misremembered about PLAT_SAMSUNG and thought it was fine because ARCH_EXYNOS no longer implied PLAT_SAMSUNG. That was wrong, instead ARCH_EXYNOS still sets PLAT_SAMSUNG but not PLAT_S5P as it used to. > So I'm sticking with the #ifdef patch for now as it > seems to be the lesser evil :-/ Yes, agreed. Arnd -- 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: S3C[24|64]xx: move includes back under scope
On Wed, Jan 15, 2014 at 10:43 AM, Arnd Bergmann wrote: > On Wednesday 15 January 2014 14:41:01 Tushar Behera wrote: >> > diff --git a/arch/arm/plat-samsung/pm-gpio.c >> > b/arch/arm/plat-samsung/pm-gpio.c >> > index c4efa1c2a5d1..a9f7a37c4173 100644 >> > --- a/arch/arm/plat-samsung/pm-gpio.c >> > +++ b/arch/arm/plat-samsung/pm-gpio.c >> > @@ -19,12 +19,7 @@ >> > #include >> > #include >> > >> > -#ifdef CONFIG_ARCH_S3C24XX >> > -#include >> > -#endif >> > -#ifdef CONFIG_ARCH_S3C64XX >> > -#include >> > -#endif >> > +#include >> >> This inclusion should be protected by a check for CONFIG_ARCH_S3C24XX >> || CONFIG_ARCH_S3C64XX. Currently generating build errors for >> s5p64x0_defconfig, s5pc100_defconfig and s5pv210_defconfig on >> next-20140115. >> > > I noticed the same problem, but I think a better solution would > be to do the same change for s5p that Linus has done for s3c, > which is to move the nonstandard contents of mach/gpio.h to > mach/gpio-samsung.h. When I look at it, the issue also exist in e.g. drivers/gpio/gpio-samsung.c which can be compiled (like for allyesconfig) when PLAT_SAMSUNG is set. And it is also set to y for ARCH_EXYNOS... which doesn't have any custom GPIO header. So this would involve something like creating an empty for Exynos which doesn't seem like the right thing to do. So I'm sticking with the #ifdef patch for now as it seems to be the lesser evil :-/ 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] ARM: S3C[24|64]xx: move includes back under scope
On Wed, Jan 15, 2014 at 10:43 AM, Arnd Bergmann wrote: > On Wednesday 15 January 2014 14:41:01 Tushar Behera wrote: >> >> This inclusion should be protected by a check for CONFIG_ARCH_S3C24XX >> || CONFIG_ARCH_S3C64XX. Currently generating build errors for >> s5p64x0_defconfig, s5pc100_defconfig and s5pv210_defconfig on >> next-20140115. > > I noticed the same problem, but I think a better solution would > be to do the same change for s5p that Linus has done for s3c, > which is to move the nonstandard contents of mach/gpio.h to > mach/gpio-samsung.h. Hm I just applied a fixup from Sachin adding #ifdefs back in but maybe I should try to fix it up like that instead. Just a minute... 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 1/1] ARM: S5P[v210|c100|64x0]: Fix build error
On Wed, Jan 15, 2014 at 10:01 AM, Sachin Kamat wrote:
> gpio-samsung.h header file introduced by commit 93177be0910c
> ("ARM: S3C[24|64]xx: move includes back under scope")
> is required only by S3C[24|64]xx machines. Include them conditionally
> to avoid the following build errors for other machine configurations.
> drivers/gpio/gpio-samsung.c:35:31: fatal error: mach/gpio-samsung.h: No such
> file or directory
> arch/arm/plat-samsung/pm-gpio.c:22:31: fatal error: mach/gpio-samsung.h: No
> such file or directory
>
> Signed-off-by: Sachin Kamat
Damned I couldn't get rid of the ifdefs anyway :-(
Thanks Sachin, patch applied.
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
[PATCH] drm/exynos: Fix multiplatform breakage for ipp
There is no need to include "plat/map-base.h" in ipp driver. Remove this and enable this driver for multi-platform. Signed-off-by: Tushar Behera --- drivers/gpu/drm/exynos/Kconfig |2 +- drivers/gpu/drm/exynos/exynos_drm_ipp.c |1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index f227f54..3af44c2 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -51,7 +51,7 @@ config DRM_EXYNOS_G2D config DRM_EXYNOS_IPP bool "Exynos DRM IPP" - depends on DRM_EXYNOS && !ARCH_MULTIPLATFORM + depends on DRM_EXYNOS help Choose this option if you want to use IPP feature for DRM. diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c b/drivers/gpu/drm/exynos/exynos_drm_ipp.c index d519a4e..eefb429 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c @@ -16,7 +16,6 @@ #include #include #include -#include #include #include -- 1.7.9.5 -- 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
Can't use the usbphy in exynos4412
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I meet the usb problem in Linux 3.13-rc8, in my board, the HSIC in SoC
is connect to usb4640, I have using a litter driver to reset usb4640
after boot.
In the old time, when it doesn't use common phy framework, it was work.
In board, the otg is brike(maybe by franklinism) but HSIC of host is
normal, I have tested.
the dmesg show that
[1.26] samsung-usb2phy 125b.usbphy: Can't get usb-phy
sysreg cfg register
[1.30] usbcore: registered new interface driver uvcvideo
[1.44] usbcore: registered new interface driver usbhid
[1.44] usbhid: USB HID core driver
[1.475000] samsung-usb2phy 125b.usbphy: Can't configure
specified phy mode
specified phy mode
root@kagami:~# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
==dts
/*
* Hardkernel's Exynos4412 based tiny4412 1306 board device tree source
*
* Copyright (c) 2013 Tomoya Gitsufuki
*
* Device tree source file for Friendyarm tiny4412 1306 board which is
based on
* Samsung's Exynos4412 SoC.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
/dts-v1/;
#include "exynos4412.dtsi"
/ {
model = "Friendly Arm Tiny4412 1306 board based on Exynos4412";
compatible = "friendlyarm,tiny4412-1306", "samsung,exynos4412";
memory {
reg = <0x4000 0x4000>;
};
chosen {
bootargs ="root=/dev/mmcblk0p1 rootfstype=ext4 rw
console=ttySAC0,115200 init=/sbin/init";
};
leds {
compatible = "gpio-leds";
led1 {
label = "led1:heart";
gpios = <&gpm4 0 1>;
default-state = "on";
linux,default-trigger = "heartbeat";
};
led2 {
label = "led2:mmc0";
gpios = <&gpm4 1 1>;
default-state = "on";
linux,default-trigger = "mmc0";
};
};
regulators {
compatible = "simple-bus";
#address-cells = <1>;
vemmc_reg: regulator-0 {
compatible = "regulator-fixed";
regulator-name = "VMEM_VDD_2.8V";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
gpio = <&gpk0 2 0>;
enable-active-high;
};
};
mshc@1255 {
num-slots = <1>;
supports-highspeed;
/*vmmc-supply = <&vemmc_reg>;*/
broken-cd;
non-removable;
card-detect-delay = <200>;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <2 3>;
samsung,dw-mshc-ddr-timing = <1 2>;
pinctrl-0 = <&sd4_clk &sd4_cmd &sd4_bus4 &sd4_bus8>;
pinctrl-names = "default";
status = "okay";
slot@0 {
reg = <0>;
bus-width = <8>;
};
};
rtc@1007 {
status = "okay";
};
sdhci@1253 {
bus-width = <4>;
pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_bus4 &sd2_cd>;
pinctrl-names = "default";
status = "okay";
};
sdhci@1254000 {
bus-width = <4>;
pinctrl-0 = <&sd3_clk &sd3_cmd &sd3_bus4 &sd3_cd>;
pinctrl-names = "default";
status = "okay";
};
usb4640 {
compatible = "smsc,usb4640";
reset-gpios = <&gpm2 4 1>;
};
usb_phy: usbphy@125B {
#address-cells = <1>;
#size-cells = <1>;
compatible = "samsung,exynos4210-usb2phy";
reg = <0x125B 0x100>;
ranges;
status = "okay";
clocks = <&clock 2>, <&clock 305>;
clock-names = "xusbxti", "otg";
usbphy-sys {
/* USB device and host PHY_CONTROL registers */
reg = <0x10020704 0x8>;
};
};
ehci@1258 {
usb-phy = <&usb_phy>;
status = "okay";
};
codec@1340 {
samsung,mfc-r = <0x4300 0x80>;
samsung,mfc-l = <0x5100 0x80>;
status = "okay";
};
serial@1380 {
status = "okay";
};
serial@1381 {
status = "okay";
};
Re: [PATCH 1/1] mmc: dw_mmc: Fix card detection regression
On 15 January 2014 15:13, zhangfei wrote:
>
>
> On 01/15/2014 05:39 PM, Sachin Kamat wrote:
>>>
>>> Thanks for the patch
>>> I just submitted one patch to fix the issue, in case you missed it.
>>
>>
>> Yes I did as I am not subscribed to mmc list.
>>
>>> Also spin_lock is required for atomic accessing DW_MMC_CARD_PRESENT.
>>> Otherwise sd detect may be failed sometimes.
>>>
>>> Could you help take a look.
>>
>>
>> I looked at and tested your patch [1] (which is similar to mine except
>> for the locking part).
>>
>> Since I do not have your patch in my mailbox, FWIW,
>>
>> Reviewed-by: Sachin Kamat
>> Tested-by: Sachin Kamat
>
>
> Thanks Sachin, that's great it works, all my mistake.
> Then I resumit the patch with this and cc you.
If you are planning to re-submit, then you may please consider
revising the commit message as follows:
s/Introdeced/Introduced
Please provide patch title after the commit Id in braces ("").
s/ingored/ignored
You may also elaborate on why IS_ERR_VALUE(!mmc_gpio_get_cd(mmc)) does not work.
--
With warm regards,
Sachin
--
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: S3C[24|64]xx: move includes back under scope
On Wednesday 15 January 2014 14:41:01 Tushar Behera wrote: > > diff --git a/arch/arm/plat-samsung/pm-gpio.c > > b/arch/arm/plat-samsung/pm-gpio.c > > index c4efa1c2a5d1..a9f7a37c4173 100644 > > --- a/arch/arm/plat-samsung/pm-gpio.c > > +++ b/arch/arm/plat-samsung/pm-gpio.c > > @@ -19,12 +19,7 @@ > > #include > > #include > > > > -#ifdef CONFIG_ARCH_S3C24XX > > -#include > > -#endif > > -#ifdef CONFIG_ARCH_S3C64XX > > -#include > > -#endif > > +#include > > This inclusion should be protected by a check for CONFIG_ARCH_S3C24XX > || CONFIG_ARCH_S3C64XX. Currently generating build errors for > s5p64x0_defconfig, s5pc100_defconfig and s5pv210_defconfig on > next-20140115. > I noticed the same problem, but I think a better solution would be to do the same change for s5p that Linus has done for s3c, which is to move the nonstandard contents of mach/gpio.h to mach/gpio-samsung.h. Arnd -- 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 1/1] mmc: dw_mmc: Fix card detection regression
On 01/15/2014 05:39 PM, Sachin Kamat wrote: Thanks for the patch I just submitted one patch to fix the issue, in case you missed it. Yes I did as I am not subscribed to mmc list. Also spin_lock is required for atomic accessing DW_MMC_CARD_PRESENT. Otherwise sd detect may be failed sometimes. Could you help take a look. I looked at and tested your patch [1] (which is similar to mine except for the locking part). Since I do not have your patch in my mailbox, FWIW, Reviewed-by: Sachin Kamat Tested-by: Sachin Kamat Thanks Sachin, that's great it works, all my mistake. Then I resumit the patch with this and cc you. 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: [PATCH 1/1] mmc: dw_mmc: Fix card detection regression
Hi Zhangfei,
On 15 January 2014 14:11, zhangfei wrote:
> Hi, Sachin
>
>
>
>
> On 01/15/2014 04:31 PM, Sachin Kamat wrote:
>>
>> mmc_gpio_get_cd returns a negative error value upon failure.
>> However gpio_cd was initialised with the negated return value
>> of the above function. This negation resulted in losing of the
>> error value thereby triggering the code to take a wrong path as
>> IS_ERR_VALUE(gpio_cd) now returned 0 even when mmc_gpio_get_cd
>> returned an error value. This issue introduced by commit bf626e5550f2
>> ("mmc: dw_mmc: use slot-gpio to handle cd pin") caused card detection
>> failure on Exynos5 boards which is now fixed by this patch.
>>
>> Signed-off-by: Sachin Kamat
>> Cc: Zhangfei Gao
>> Cc: Jaehoon Chung
>> Cc: Arnd Bergmann
>> ---
>
>
> Thanks for the patch
> I just submitted one patch to fix the issue, in case you missed it.
Yes I did as I am not subscribed to mmc list.
> Also spin_lock is required for atomic accessing DW_MMC_CARD_PRESENT.
> Otherwise sd detect may be failed sometimes.
>
> Could you help take a look.
I looked at and tested your patch [1] (which is similar to mine except
for the locking part).
Since I do not have your patch in my mailbox, FWIW,
Reviewed-by: Sachin Kamat
Tested-by: Sachin Kamat
[1] http://permalink.gmane.org/gmane.linux.kernel.mmc/24600
---
With warm regards,
Sachin
--
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
[PATCH 8/8 v4] crypto:s5p-sss: Use clk_prepare/clk_unprepare
This patch set adds use of clk_prepare/clk_unprepare as required by generic clock framework. Signed-off-by: Naveen Krishna Chatradhi Reviewed-by: Tomasz Figa --- Changes since v3: None drivers/crypto/s5p-sss.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c index f7c66c7..870e794 100644 --- a/drivers/crypto/s5p-sss.c +++ b/drivers/crypto/s5p-sss.c @@ -648,7 +648,7 @@ static int s5p_aes_probe(struct platform_device *pdev) return -ENOENT; } - clk_enable(pdata->clk); + clk_prepare_enable(pdata->clk); spin_lock_init(&pdata->lock); pdata->ioaddr = devm_ioremap(dev, res->start, @@ -711,7 +711,7 @@ static int s5p_aes_probe(struct platform_device *pdev) tasklet_kill(&pdata->tasklet); err_irq: - clk_disable(pdata->clk); + clk_disable_unprepare(pdata->clk); s5p_dev = NULL; @@ -731,7 +731,7 @@ static int s5p_aes_remove(struct platform_device *pdev) tasklet_kill(&pdata->tasklet); - clk_disable(pdata->clk); + clk_disable_unprepare(pdata->clk); s5p_dev = NULL; -- 1.7.9.5 -- 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
[PATCH 5/8 v4] clk: samsung: exynos5250/5420: Add gate clock for SSS module
This patch adds gating clock for SSS(Security SubSystem)
module on Exynos5250/5420.
Signed-off-by: Naveen Krishna Chatradhi
TO:
TO: Tomasz Figa
CC: Kukjin Kim
CC:
---
Changes since v3:
1. Rebased on to
https://git.kernel.org/pub/scm/linux/kernel/git/tfiga/samsung-clk.git
2. Added new ID for SSS clock on Exynos5250, with Documentation and
3. Added gate clocks definitions for SSS on Exynos5420 and Exynos5250
.../devicetree/bindings/clock/exynos5250-clock.txt |1 +
drivers/clk/samsung/clk-exynos5250.c |1 +
drivers/clk/samsung/clk-exynos5420.c |4
include/dt-bindings/clock/exynos5250.h |1 +
4 files changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 492ed09..a845fc6 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -162,6 +162,7 @@ clock which they consume.
g2d 345
mdma0346
smmu_mdma0 347
+ sss 348
[Clock Muxes]
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c
index ff4beeb..2c52fe1 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -387,6 +387,7 @@ static struct samsung_gate_clock exynos5250_gate_clks[]
__initdata = {
* CMU_ACP
*/
GATE(CLK_MDMA0, "mdma0", "div_aclk266", GATE_IP_ACP, 1, 0, 0),
+ GATE(CLK_SSS, "sss", "div_aclk266", GATE_IP_ACP, 2, 0, 0),
GATE(CLK_G2D, "g2d", "div_aclk200", GATE_IP_ACP, 3, 0, 0),
GATE(CLK_SMMU_MDMA0, "smmu_mdma0", "div_aclk266", GATE_IP_ACP, 5, 0, 0),
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index ab4f2f7..94915bb 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -26,6 +26,7 @@
#define DIV_CPU1 0x504
#define GATE_BUS_CPU 0x700
#define GATE_SCLK_CPU 0x800
+#define GATE_BUS_G2D 0x8700
#define CPLL_LOCK 0x10020
#define DPLL_LOCK 0x10030
#define EPLL_LOCK 0x10040
@@ -702,6 +703,9 @@ static struct samsung_gate_clock exynos5420_gate_clks[]
__initdata = {
0),
GATE(CLK_SMMU_MIXER, "smmu_mixer", "aclk200_disp1", GATE_IP_DISP1, 9, 0,
0),
+
+ /* SSS */
+ GATE(CLK_SSS, "sss", "aclk266_g2d", GATE_BUS_G2D, 2, 0, 0),
};
static struct samsung_pll_clock exynos5420_plls[nr_plls] __initdata = {
diff --git a/include/dt-bindings/clock/exynos5250.h
b/include/dt-bindings/clock/exynos5250.h
index 922f2dc..f9b452b 100644
--- a/include/dt-bindings/clock/exynos5250.h
+++ b/include/dt-bindings/clock/exynos5250.h
@@ -150,6 +150,7 @@
#define CLK_G2D345
#define CLK_MDMA0 346
#define CLK_SMMU_MDMA0 347
+#define CLK_SSS348
/* mux clocks */
#define CLK_MOUT_HDMI 1024
--
1.7.9.5
--
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
[PATCH 6/8 v4] ARM: dts: exynos5250/5420: add dt node for sss module
This patch adds the device tree node for SSS module
found on Exynos5420 and Exynos5250
Signed-off-by: Naveen Krishna Chatradhi
Reviewed-by: Tomasz Figa
TO:
CC: Kukjin Kim
CC:
---
Changes since v3:
1. Modified the SSS clock ID as per dt-bindings for Exynos5250 in
samsung-clk.git tree.
arch/arm/boot/dts/exynos5250.dtsi |8
arch/arm/boot/dts/exynos5420.dtsi | 10 ++
2 files changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index c341e55..1d249df 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -704,4 +704,12 @@
io-channel-ranges;
status = "disabled";
};
+
+ sss@1083 {
+ compatible = "samsung,exynos4210-secss";
+ reg = <0x1083 0x1>;
+ interrupts = <0 112 0>;
+ clocks = <&clock 348>;
+ clock-names = "secss";
+ };
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 11dd202..56a3f3e 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -652,4 +652,14 @@
clocks = <&clock 319>, <&clock 318>;
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
};
+
+ sss@1083 {
+ compatible = "samsung,exynos4210-secss";
+ reg = <0x1083 0x1>;
+ interrupts = <0 112 0>;
+ clocks = <&clock 471>;
+ clock-names = "secss";
+ samsung,power-domain = <&g2d_pd>;
+ };
+
};
--
1.7.9.5
--
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
[PATCH 4/8 v4] crypto:s5p-sss: Kconfig: Let Exynos SoCs select SSS driver
From: Naveen Krishna Ch This patch modifies Kconfig such that ARCH_EXYNOS SoCs which includes (Exynos4210, Exynos5250 and Exynos5420) can also select Samsung SSS(Security SubSystem) driver. Signed-off-by: Naveen Krishna Ch CC: Herbert Xu CC: David S. Miller CC: Vladimir Zapolskiy TO: CC: --- Changes since v3: Modified description to use "Exynos" instead of individual SoC name drivers/crypto/Kconfig |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index f4fd837..cb38863 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -300,14 +300,14 @@ config CRYPTO_DEV_DCP capabilities of the DCP co-processor config CRYPTO_DEV_S5P - tristate "Support for Samsung S5PV210 crypto accelerator" - depends on ARCH_S5PV210 + tristate "Support for Samsung S5PV210/Exynos crypto accelerator" + depends on ARCH_S5PV210 || ARCH_EXYNOS select CRYPTO_AES select CRYPTO_ALGAPI select CRYPTO_BLKCIPHER help This option allows you to have support for S5P crypto acceleration. - Select this to offload Samsung S5PV210 or S5PC110 from AES + Select this to offload Samsung S5PV210 or S5PC110, Exynos from AES algorithms execution. config CRYPTO_DEV_TEGRA_AES -- 1.7.9.5 -- 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
[PATCH 7/8 v4] crypto:s5p-sss: validate iv before memcpy
This patch adds code to validate "iv" buffer before trying to
memcpy the contents
Signed-off-by: Naveen Krishna Chatradhi
---
Changes since v3:
None
drivers/crypto/s5p-sss.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 69130b2..f7c66c7 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -380,7 +380,8 @@ static void s5p_set_aes(struct s5p_aes_dev *dev,
{
void __iomem *keystart;
- memcpy(dev->aes_ioaddr + SSS_REG_AES_IV_DATA (0), iv, 0x10);
+ if (iv)
+ memcpy(dev->aes_ioaddr + SSS_REG_AES_IV_DATA (0), iv, 0x10);
if (keylen == AES_KEYSIZE_256)
keystart = dev->aes_ioaddr + SSS_REG_AES_KEY_DATA(0);
--
1.7.9.5
--
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
[PATCH 3/8 v4] crypto:s5p-sss: Add support for SSS module on Exynos
This patch adds new compatible and variant struct to support the SSS
module on Exynos4 (Exynos4210), Exynos5 (Exynos5420 and Exynos5250)
for which
1. AES register are at an offset of 0x200 and
2. hash interrupt is not available
Signed-off-by: Naveen Krishna Ch
CC: Herbert Xu
CC: David S. Miller
CC: Vladimir Zapolskiy
TO:
CC:
---
Changes since v3:
1. Implemented aes_ioaddr to handle AES register offset, suggested by Tomasz
.../devicetree/bindings/crypto/samsung-sss.txt | 30 +-
drivers/crypto/s5p-sss.c | 107 +++-
2 files changed, 110 insertions(+), 27 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
index 2f9d7e4..b99c445 100644
--- a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
+++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
@@ -8,13 +8,37 @@ The SSS module in S5PV210 SoC supports the following:
-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
-- PRNG: Pseudo Random Number Generator
+The SSS module in Exynos4 (Exynos4210) and
+Exynos5 (Exynos5420 and Exynos5250) SoCs
+supports the following also:
+-- ARCFOUR (ARC4)
+-- True Random Number Generator (TRNG)
+-- Secure Key Manager
+
Required properties:
- compatible : Should contain entries for this and backward compatible
SSS versions:
- "samsung,s5pv210-secss" for S5PV210 SoC.
+ - "samsung,exynos4210-secss" for Exynos4210, Exynos4212, Exynos4412,
Exynos5250,
+ Exynos5260 and Exynos5420 SoCs.
- reg : Offset and length of the register set for the module
- interrupts : the interrupt-specifier for the SSS module.
- Two interrupts "feed control and hash" in case of S5PV210
-- clocks : the required gating clock for the SSS module.
-- clock-names : the gating clock name to be requested in the SSS driver.
+ -- Two interrupts "feed control and hash" in case of
+ "samsung,s5pv210-secss"
+ -- One interrupts "feed control" in case of
+ "samsung,exynos4210-secss".
+- clocks : list of clock phandle and specifier pairs for all clocks listed in
+ clock-names property.
+- clock-names : list of device clock input names; should contain one entry
+ "secss".
+
+Example:
+ /* SSS_VER_5 */
+ sss@1083 {
+ compatible = "samsung,exynos4210-secss";
+ reg = <0x1083 0x1>;
+ interrupts = <0 112 0>;
+ clocks = <&clock 471>;
+ clock-names = "secss";
+ };
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 2da5617..69130b2 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -106,7 +106,7 @@
#define SSS_REG_FCPKDMAO0x005C
/* AES registers */
-#define SSS_REG_AES_CONTROL 0x4000
+#define SSS_REG_AES_CONTROL0x00
#define SSS_AES_BYTESWAP_DI _BIT(11)
#define SSS_AES_BYTESWAP_DO _BIT(10)
#define SSS_AES_BYTESWAP_IV _BIT(9)
@@ -122,21 +122,25 @@
#define SSS_AES_CHAIN_MODE_CTR _SBF(1, 0x02)
#define SSS_AES_MODE_DECRYPT_BIT(0)
-#define SSS_REG_AES_STATUS 0x4004
+#define SSS_REG_AES_STATUS 0x04
#define SSS_AES_BUSY_BIT(2)
#define SSS_AES_INPUT_READY _BIT(1)
#define SSS_AES_OUTPUT_READY_BIT(0)
-#define SSS_REG_AES_IN_DATA(s) (0x4010 + (s << 2))
-#define SSS_REG_AES_OUT_DATA(s) (0x4020 + (s << 2))
-#define SSS_REG_AES_IV_DATA(s) (0x4030 + (s << 2))
-#define SSS_REG_AES_CNT_DATA(s) (0x4040 + (s << 2))
-#define SSS_REG_AES_KEY_DATA(s) (0x4080 + (s << 2))
+#define SSS_REG_AES_IN_DATA(s) (0x10 + (s << 2))
+#define SSS_REG_AES_OUT_DATA(s)(0x20 + (s << 2))
+#define SSS_REG_AES_IV_DATA(s) (0x30 + (s << 2))
+#define SSS_REG_AES_CNT_DATA(s)(0x40 + (s << 2))
+#define SSS_REG_AES_KEY_DATA(s)(0x80 + (s << 2))
#define SSS_REG(dev, reg) ((dev)->ioaddr + (SSS_REG_##reg))
#define SSS_READ(dev, reg) __raw_readl(SSS_REG(dev, reg))
#define SSS_WRITE(dev, reg, val)__raw_writel((val), SSS_REG(dev, reg))
+#define SSS_AES_REG(dev, reg) ((dev)->aes_ioaddr + SSS_REG_##reg)
+#define SSS_AES_WRITE(dev, reg, val)__raw_writel((val), \
+ SSS_AES_REG(dev, reg))
+
/* HW engine modes */
#define FLAGS_AES_DECRYPT _BIT(0)
#define FLAGS_AES_MODE_MASK _SBF(1, 0x03)
@@ -146,6 +150,20 @@
#define AES_KEY_LEN 16
#define CRYPTO_QUEUE_LEN1
+/**
+ * struct samsung_aes_variant - platform specific SSS driver data
+ * @has_hash_irq: true if SSS module uses hash interrupt, false otherwise
+ * @aes_offset: AES register offset from SSS module's base.
+ *
+ * Specifies pla
[PATCH 1/8 v4] crypto:s5p-sss: Use platform_get_irq() instead of _byname()
From: Naveen Krishna Ch
This patch uses the platform_get_irq() instead of the
platform_get_irq_byname(). Making feeder control interrupt
as resource "0" and hash interrupt as "1".
reasons for this change.
1. Cannot find any Arch which is currently using this driver
2. Samsung Exynos4 and 5 SoCs only use the feeder control interrupt
3. Patches adding support for DT and H/W version are in pipeline
Signed-off-by: Naveen Krishna Ch
Reviewed-by: Tomasz Figa
CC: Herbert Xu
CC: David S. Miller
CC: Vladimir Zapolskiy
TO:
CC:
---
Changes since v3:
None
drivers/crypto/s5p-sss.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index cf149b1..93cddeb 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -592,29 +592,29 @@ static int s5p_aes_probe(struct platform_device *pdev)
pdata->ioaddr = devm_ioremap(dev, res->start,
resource_size(res));
- pdata->irq_hash = platform_get_irq_byname(pdev, "hash");
- if (pdata->irq_hash < 0) {
- err = pdata->irq_hash;
- dev_warn(dev, "hash interrupt is not available.\n");
+ pdata->irq_fc = platform_get_irq(pdev, 0);
+ if (pdata->irq_fc < 0) {
+ err = pdata->irq_fc;
+ dev_warn(dev, "feed control interrupt is not available.\n");
goto err_irq;
}
- err = devm_request_irq(dev, pdata->irq_hash, s5p_aes_interrupt,
+ err = devm_request_irq(dev, pdata->irq_fc, s5p_aes_interrupt,
IRQF_SHARED, pdev->name, pdev);
if (err < 0) {
- dev_warn(dev, "hash interrupt is not available.\n");
+ dev_warn(dev, "feed control interrupt is not available.\n");
goto err_irq;
}
- pdata->irq_fc = platform_get_irq_byname(pdev, "feed control");
- if (pdata->irq_fc < 0) {
- err = pdata->irq_fc;
- dev_warn(dev, "feed control interrupt is not available.\n");
+ pdata->irq_hash = platform_get_irq(pdev, 1);
+ if (pdata->irq_hash < 0) {
+ err = pdata->irq_hash;
+ dev_warn(dev, "hash interrupt is not available.\n");
goto err_irq;
}
- err = devm_request_irq(dev, pdata->irq_fc, s5p_aes_interrupt,
+ err = devm_request_irq(dev, pdata->irq_hash, s5p_aes_interrupt,
IRQF_SHARED, pdev->name, pdev);
if (err < 0) {
- dev_warn(dev, "feed control interrupt is not available.\n");
+ dev_warn(dev, "hash interrupt is not available.\n");
goto err_irq;
}
--
1.7.9.5
--
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
[PATCH 2/8 v4] crypto:s5p-sss: Add device tree support
This patch adds device tree support to the s5p-sss.c crypto driver.
Also, Documentation under devicetree/bindings added.
Signed-off-by: Naveen Krishna Ch
CC: Herbert Xu
CC: David S. Miller
CC: Vladimir Zapolskiy
TO:
CC:
---
Changes since v3:
None
.../devicetree/bindings/crypto/samsung-sss.txt | 20
drivers/crypto/s5p-sss.c | 10 +-
2 files changed, 29 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/crypto/samsung-sss.txt
diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
new file mode 100644
index 000..2f9d7e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
@@ -0,0 +1,20 @@
+Samsung SoC SSS (Security SubSystem) module
+
+The SSS module in S5PV210 SoC supports the following:
+-- Feeder (FeedCtrl)
+-- Advanced Encryption Standard (AES)
+-- Data Encryption Standard (DES)/3DES
+-- Public Key Accelerator (PKA)
+-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
+-- PRNG: Pseudo Random Number Generator
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+ SSS versions:
+ - "samsung,s5pv210-secss" for S5PV210 SoC.
+- reg : Offset and length of the register set for the module
+- interrupts : the interrupt-specifier for the SSS module.
+ Two interrupts "feed control and hash" in case of S5PV210
+- clocks : the required gating clock for the SSS module.
+- clock-names : the gating clock name to be requested in the SSS driver.
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 93cddeb..2da5617 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -177,6 +178,12 @@ struct s5p_aes_dev {
static struct s5p_aes_dev *s5p_dev;
+static const struct of_device_id s5p_sss_dt_match[] = {
+ { .compatible = "samsung,s5pv210-secss", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, s5p_sss_dt_match);
+
static void s5p_set_dma_indata(struct s5p_aes_dev *dev, struct scatterlist *sg)
{
SSS_WRITE(dev, FCBRDMAS, sg_dma_address(sg));
@@ -676,7 +683,8 @@ static struct platform_driver s5p_aes_crypto = {
.remove = s5p_aes_remove,
.driver = {
.owner = THIS_MODULE,
- .name = "s5p-secss",
+ .name = "s5pv210-secss",
+ .of_match_table = s5p_sss_dt_match,
},
};
--
1.7.9.5
--
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: S3C[24|64]xx: move includes back under scope
On 14 January 2014 19:23, Linus Walleij wrote: > When refactoring and breaking out the includes for the > machine-specific GPIO configuration, two files were created > in , but as > that namespace shall be used for defining data exchanged > between machines and drivers, using it for these broad macros > and config settings is wrong. > > Move the headers back into the machine-local > file and think about the next step. > > diff --git a/arch/arm/plat-samsung/pm-gpio.c b/arch/arm/plat-samsung/pm-gpio.c > index c4efa1c2a5d1..a9f7a37c4173 100644 > --- a/arch/arm/plat-samsung/pm-gpio.c > +++ b/arch/arm/plat-samsung/pm-gpio.c > @@ -19,12 +19,7 @@ > #include > #include > > -#ifdef CONFIG_ARCH_S3C24XX > -#include > -#endif > -#ifdef CONFIG_ARCH_S3C64XX > -#include > -#endif > +#include This inclusion should be protected by a check for CONFIG_ARCH_S3C24XX || CONFIG_ARCH_S3C64XX. Currently generating build errors for s5p64x0_defconfig, s5pc100_defconfig and s5pv210_defconfig on next-20140115. -- Tushar Behera -- 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
[PATCH 1/1] ARM: S5P[v210|c100|64x0]: Fix build error
gpio-samsung.h header file introduced by commit 93177be0910c
("ARM: S3C[24|64]xx: move includes back under scope")
is required only by S3C[24|64]xx machines. Include them conditionally
to avoid the following build errors for other machine configurations.
drivers/gpio/gpio-samsung.c:35:31: fatal error: mach/gpio-samsung.h: No such
file or directory
arch/arm/plat-samsung/pm-gpio.c:22:31: fatal error: mach/gpio-samsung.h: No
such file or directory
Signed-off-by: Sachin Kamat
---
Only compile tested.
---
arch/arm/plat-samsung/pm-gpio.c |3 +++
drivers/gpio/gpio-samsung.c |3 +++
2 files changed, 6 insertions(+)
diff --git a/arch/arm/plat-samsung/pm-gpio.c b/arch/arm/plat-samsung/pm-gpio.c
index a9f7a37c4173..dd4c15d0d68f 100644
--- a/arch/arm/plat-samsung/pm-gpio.c
+++ b/arch/arm/plat-samsung/pm-gpio.c
@@ -19,7 +19,10 @@
#include
#include
+#if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S3C64XX)
#include
+#endif
+
#include
#include
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index 9741cce11df5..a85e00bf9834 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -32,7 +32,10 @@
#include
#include
+
+#if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S3C64XX)
#include
+#endif
#include
#include
--
1.7.9.5
--
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 5/8 v3] clk:exynos-5250: Add gate clock for SSS module
Hello Tomasz,
On 10 January 2014 21:28, Tomasz Figa wrote:
> Hi Naveen,
>
>
> On 10.01.2014 12:43, Naveen Krishna Chatradhi wrote:
>>
>> This patch adds gating clock for SSS(Security SubSystem)
>> module on Exynos5250.
>>
>> Signed-off-by: Naveen Krishna Chatradhi
>> ---
>> Changes since v2:
>> This is a new change to support SSS on Exynos5250
>>
>> drivers/clk/samsung/clk-exynos5250.c |3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/samsung/clk-exynos5250.c
>> b/drivers/clk/samsung/clk-exynos5250.c
>> index adf3234..b47bf0a 100644
>> --- a/drivers/clk/samsung/clk-exynos5250.c
>> +++ b/drivers/clk/samsung/clk-exynos5250.c
>> @@ -120,7 +120,7 @@ enum exynos5250_clks {
>> spi2, i2s1, i2s2, pcm1, pcm2, pwm, spdif, ac97, hsi2c0, hsi2c1,
>> hsi2c2,
>> hsi2c3, chipid, sysreg, pmu, cmu_top, cmu_core, cmu_mem, tzpc0,
>> tzpc1,
>> tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec,
>> mct,
>> - wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi, g2d,
>> + wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi, g2d, sss,
>
>
> Please base changes to Samsung clock drivers on Mike Turquette's clk-next
> [1] or ideally on my samsung-next branch on samsung-clk-tree [2].
>
> By the way, if you assign an ID to a clock, you need to document this in
> respective clock bindings documentation.
>
> [1] - https://git.linaro.org/people/mike.turquette/linux.git
> [2] - https://git.kernel.org/cgit/linux/kernel/git/tfiga/samsung-clk.git/
Sure Tomasz, Will rebase this changes on to your samsung-clk.git tree
>
> Best regards,
> Tomasz
--
Shine bright,
(: Nav :)
--
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 1/1] mmc: dw_mmc: Fix card detection regression
Hi, Sachin
On 01/15/2014 04:31 PM, Sachin Kamat wrote:
mmc_gpio_get_cd returns a negative error value upon failure.
However gpio_cd was initialised with the negated return value
of the above function. This negation resulted in losing of the
error value thereby triggering the code to take a wrong path as
IS_ERR_VALUE(gpio_cd) now returned 0 even when mmc_gpio_get_cd
returned an error value. This issue introduced by commit bf626e5550f2
("mmc: dw_mmc: use slot-gpio to handle cd pin") caused card detection
failure on Exynos5 boards which is now fixed by this patch.
Signed-off-by: Sachin Kamat
Cc: Zhangfei Gao
Cc: Jaehoon Chung
Cc: Arnd Bergmann
---
Thanks for the patch
I just submitted one patch to fix the issue, in case you missed it.
Also spin_lock is required for atomic accessing DW_MMC_CARD_PRESENT.
Otherwise sd detect may be failed sometimes.
Could you help take a look.
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
[PATCH 1/1] mmc: dw_mmc: Fix card detection regression
mmc_gpio_get_cd returns a negative error value upon failure.
However gpio_cd was initialised with the negated return value
of the above function. This negation resulted in losing of the
error value thereby triggering the code to take a wrong path as
IS_ERR_VALUE(gpio_cd) now returned 0 even when mmc_gpio_get_cd
returned an error value. This issue introduced by commit bf626e5550f2
("mmc: dw_mmc: use slot-gpio to handle cd pin") caused card detection
failure on Exynos5 boards which is now fixed by this patch.
Signed-off-by: Sachin Kamat
Cc: Zhangfei Gao
Cc: Jaehoon Chung
Cc: Arnd Bergmann
---
drivers/mmc/host/dw_mmc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index a776f24f4311..f1683ba194ee 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1033,7 +1033,7 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
int present;
struct dw_mci_slot *slot = mmc_priv(mmc);
struct dw_mci_board *brd = slot->host->pdata;
- int gpio_cd = !mmc_gpio_get_cd(mmc);
+ int gpio_cd = mmc_gpio_get_cd(mmc);
/* Use platform get_cd function, else try onboard card detect */
if (brd->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
@@ -1041,7 +1041,7 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
else if (brd->get_cd)
present = !brd->get_cd(slot->id);
else if (!IS_ERR_VALUE(gpio_cd))
- present = !!gpio_cd;
+ present = !gpio_cd;
else
present = (mci_readl(slot->host, CDETECT) & (1 << slot->id))
== 0 ? 1 : 0;
--
1.7.9.5
--
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
