Re: State of pinctrl and exynos5250?
On Wed, Mar 6, 2013 at 12:49 AM, Thomas Abraham
wrote:
> Yes, I am currently held up with supporting default pin states at slot
> level. One option that could be considered is to list out the default
> pin states for all slots in the parent node of the slots. So it would
> be something like below as an example.
>
> dwmmc2@1222 {
><>
>
> pinctrl-names = "slot0-default", "slot1-default";
> pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
> pinctrl-1 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4 &sd2_bus8>;
>
> slot@0 {
> reg = <0>;
> bus-width = <4>;
> disable-wp;
> };
>
> slot@1 {
> reg = <0>;
> bus-width = <8>;
> disable-wp;
> };
> };
I don't quite understand the above. Is it such that there is one device,
with two slots, and in the device model you have represented this
two-slot device with a single struct device?
Have you considered just registering one device for each slot?
That would make things quite a lot simpler, just a single pinctrl
handle per device, right?
You need to pass this by Stephen Warren, I think he had a similar
case in the Tegra.
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 00/23] RFC: exynos multiplatform support
On Thu, Mar 07, 2013 at 03:02:46AM +, Arnd Bergmann wrote: > On Wednesday 06 March 2013, Thierry Reding wrote: > > > Option 2 would probably come down to having a trivial MFD driver exposing > > > a regmap. You can probably reuse drivers/mfd/syscon.c for this and make > > > the node compatible with "syscon" to designate the clock registers as > > > a system-wide resource, making the other device nodes register-less. > > > > I think option 2 is the standard method if one hardware block provides > > several logical devices. I find it to be a pretty nice solution to this > > problem. We also have precedent in the PWM subsystem. The TWL chips for > > instance use it to create a platform device which is later driven by a > > PWM driver. > > One difference though is that the TWL chip is a heterogenous MFD that has > a lot of different sub-devices, where in case of Exynos the timer device > has a set of identical units, each of which can be used either as a PWM or > as a clocksource or other timer. I didn't know that. However I still making this an MFD driver is a good fit because it'll move the logic of defining the mode of each unit is kept in a parent driver which can instantiate the proper child devices for the corresponding subsystems. One big disadvantage of this approach is that if this is continued there is a risk that MFD will turn into a dump for all kinds of devices that provide more than a single service. So if people prefer option 3 I'm fine with it as well. Thierry pgpMP5SktmGM4.pgp Description: PGP signature
Re: [PATCH RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver
On Wed, Mar 6, 2013 at 8:43 PM, Inki Dae wrote: > 2013/3/7 김승우 : >> >> >> On 2013년 03월 04일 23:05, Rahul Sharma wrote: >>> Thanks Sean, >>> >>> On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul wrote: On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma wrote: > Right now hdmiphy operations and configs are kept inside hdmi driver. > hdmiphy related > code is tightly coupled with hdmi ip driver. Physicaly they are different > devices and s/Physicaly/Physically/ > should be instantiated independently. > > In terms of versions/mapping/configurations Hdmi and hdmiphy are > independent of each > other. It is preferred to isolate them and maintained independently. > > This implementations is tested for: > 1) Resolutions supported by exynos4 and 5 hdmi. > 2) Runtime PM and S2R scenarions for exynos5. > I don't like the idea of spawning off yet another driver in here. It adds more globals, more suspend/resume ordering issues, and more implicit dependencies. I understand, however, that this is the Chosen Way for the exynos driver, so I will save my rant. >>> >>> I agree to it. splitting phy to a new driver will complicate the power >>> related >>> scenarios. But in upcoming SoC,s, Phy is changing considerably in terms of >>> config values, mapping (i2c/platform bus) etc. Handling this diversity >>> inside hdmi driver is complicating it with unrelated changes. >> >> Basically, I agree with the idea to split hdmiphy from hdmi. And it >> seems that already existing hdmiphy i2c device is just reused and >> hdmiphy_power_on is reorganized to hdmiphy dpms operation: even calling >> flow of power operations is reordered. >> >> But I'm not sure exynos_hdmiphy_driver_register() really need to be >> called from exynos_drm_init() of exynos_drm_drv.c. IMO, it is enough to >> call exynos_hdmiphy_driver_register() from hdmi_probe() because hdmiphy >> is only used from hdmi. >> > > I agree with Seung-Woo. The hdmiphy is just one part of HDMI subsystem. > But this is probably going to break dpms and/or suspend/resume functionality. Has that been tested? Stéphane > Thanks, > Inki Dae > >> Thanks and Regards, >> - Seung-Woo Kim >> >>> >>> I have tested this RFC for Runtime PM / S2R. But if we see any major >>> roadblock >>> we should re-factor this by explicitly calling power related callbacks >>> of mixer, phy, >>> hdmi drivers in a required order. We can call them from exynos-drm-hdmi plf >>> device. AFAIR something like this is already in place in chrome-kernel. >>> I've made some comments below. > This patch is dependent on > http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34733.html > http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34861.html > http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34862.html > > Signed-off-by: Rahul Sharma > --- > It is based on exynos-drm-next-todo branch at > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > > drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 + > drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 + > drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 58 ++- > drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 + > drivers/gpu/drm/exynos/exynos_hdmi.c | 375 ++-- > drivers/gpu/drm/exynos/exynos_hdmi.h | 1 - > drivers/gpu/drm/exynos/exynos_hdmiphy.c | 586 > ++- > drivers/gpu/drm/exynos/regs-hdmiphy.h| 61 > 8 files changed, 738 insertions(+), 368 deletions(-) > create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h > >> >> >> >> -- >> Seung-Woo Kim >> Samsung Software R&D Center >> -- >> >> ___ >> dri-devel mailing list >> dri-de...@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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 RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver
On 2013년 03월 07일 15:45, Rahul Sharma wrote: > Thanks Seung Woo, Mr. Dae, > > On Thu, Mar 7, 2013 at 10:13 AM, Inki Dae wrote: >> 2013/3/7 김승우 : >>> >>> >>> On 2013년 03월 04일 23:05, Rahul Sharma wrote: Thanks Sean, On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul wrote: > On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma > wrote: >> Right now hdmiphy operations and configs are kept inside hdmi driver. >> hdmiphy related >> code is tightly coupled with hdmi ip driver. Physicaly they are >> different devices and > > s/Physicaly/Physically/ > >> should be instantiated independently. >> >> In terms of versions/mapping/configurations Hdmi and hdmiphy are >> independent of each >> other. It is preferred to isolate them and maintained independently. >> >> This implementations is tested for: >> 1) Resolutions supported by exynos4 and 5 hdmi. >> 2) Runtime PM and S2R scenarions for exynos5. >> > > I don't like the idea of spawning off yet another driver in here. It > adds more globals, more suspend/resume ordering issues, and more > implicit dependencies. I understand, however, that this is the Chosen > Way for the exynos driver, so I will save my rant. > I agree to it. splitting phy to a new driver will complicate the power related scenarios. But in upcoming SoC,s, Phy is changing considerably in terms of config values, mapping (i2c/platform bus) etc. Handling this diversity inside hdmi driver is complicating it with unrelated changes. >>> >>> Basically, I agree with the idea to split hdmiphy from hdmi. And it >>> seems that already existing hdmiphy i2c device is just reused and >>> hdmiphy_power_on is reorganized to hdmiphy dpms operation: even calling >>> flow of power operations is reordered. >>> >>> But I'm not sure exynos_hdmiphy_driver_register() really need to be >>> called from exynos_drm_init() of exynos_drm_drv.c. IMO, it is enough to >>> call exynos_hdmiphy_driver_register() from hdmi_probe() because hdmiphy >>> is only used from hdmi. >>> >> >> I agree with Seung-Woo. The hdmiphy is just one part of HDMI subsystem. >> > > I agree to the Seung Woo's point that hdmi-phy used to be solely accessed by > hdmi driver. But in this RFC, hdmi-phy is not called by hdmi driver > anymore. Phy > ops will be called from drm-common-hdmi platform driver along with mixer and > hdmi ops. Considering this, exynos_drm_hdmi_probe() is more proper position. > > The rational behind my implementation is that I am projecting hdmi-phy as > a device which is peer to hdmi ip and mixer. These 3 devices together makes > DRM HDMI subsystem. > > Even physically hdmi-phy doesn't seems to be a part of hdmi ip though > configurations are listed under hdmi ip user manual. It looks like a > isolated module accessed by i2c. > > Though I don't find anything wrong with Seung Woo suggestion but above > placement of hdmi-phy (parallel to hdmi and mixer) makes more sense > to me. > > Please have a another look at it and let me know your opinion. > > Another things which bothers me is registering mixer, hdmi driver inside > exynos_drm_init(). If we strictly follow the hierarchy inside drm, > exynos_drm_init() > should register drm-common-hdmi only. drm-common-hdmi should register > mixer and hdmi (or hdmi-phy as well). Yes, it makes sense. All real hw blocks for hdmi including mixer, hdmi, and hdmiphy shoulde be registered in exynos_drm_hdmi (drm-common-hdmi for exynos). Thanks and Regards, - Seung-Woo Kim > > regards, > Rahul Sharma. > >> Thanks, >> Inki Dae >> >>> Thanks and Regards, >>> - Seung-Woo Kim >>> I have tested this RFC for Runtime PM / S2R. But if we see any major roadblock we should re-factor this by explicitly calling power related callbacks of mixer, phy, hdmi drivers in a required order. We can call them from exynos-drm-hdmi plf device. AFAIR something like this is already in place in chrome-kernel. > I've made some comments below. > >> This patch is dependent on >> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34733.html >> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34861.html >> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34862.html >> >> Signed-off-by: Rahul Sharma >> --- >> It is based on exynos-drm-next-todo branch at >> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git >> >> drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 + >> drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 + >> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 58 ++- >> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 + >> drivers/gpu/drm/exynos/exynos_hdmi.c | 375 ++-- >> drivers/gpu/drm/exynos/exynos_hdmi.h | 1 - >> drivers/gpu/drm/exynos/exynos_hdmiphy.c | 586 >>
Re: [PATCH v6 5/5] ARM: dts: Add FIMD DT binding Documentation
Hi,
On 7 March 2013 02:43, Sylwester Nawrocki wrote:
> On 03/06/2013 11:18 AM, Vikas Sajjan wrote:
>>
>> Good idea, but i am just wondering is it a good idea to modify the
>> fimd driver ?
>
>
> I think it is. But it depends what code quality you aim for.
>
> Is there any issue in making a change as below ? ;)
Certainly no issue :-) Will check this idea both on exyno4 and
exynos5 and shall update.
>
> Of course it's all up to you, I've just suggested what I thought was
> an improvement to the current situation.
>
> diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
> index 51afedd..4180247 100644
> --- a/arch/arm/plat-samsung/devs.c
> +++ b/arch/arm/plat-samsung/devs.c
> @@ -160,9 +160,9 @@ struct platform_device samsung_asoc_idma = {
> #ifdef CONFIG_S3C_DEV_FB
> static struct resource s3c_fb_resource[] = {
> [0] = DEFINE_RES_MEM(S3C_PA_FB, SZ_16K),
> - [1] = DEFINE_RES_IRQ(IRQ_LCD_VSYNC),
> - [2] = DEFINE_RES_IRQ(IRQ_LCD_FIFO),
> - [3] = DEFINE_RES_IRQ(IRQ_LCD_SYSTEM),
> + [1] = DEFINE_RES_IRQ_NAMED(IRQ_LCD_VSYNC, "vsync"),
> + [2] = DEFINE_RES_IRQ_NAMED(IRQ_LCD_FIFO, "fifo"),
> + [3] = DEFINE_RES_IRQ_NAMED(IRQ_LCD_SYSTEM, "system"),
> };
>
> struct platform_device s3c_device_fb = {
> @@ -305,9 +305,9 @@ struct platform_device s5p_device_jpeg = {
> #ifdef CONFIG_S5P_DEV_FIMD0
> static struct resource s5p_fimd0_resource[] = {
> [0] = DEFINE_RES_MEM(S5P_PA_FIMD0, SZ_32K),
> - [1] = DEFINE_RES_IRQ(IRQ_FIMD0_VSYNC),
> - [2] = DEFINE_RES_IRQ(IRQ_FIMD0_FIFO),
> - [3] = DEFINE_RES_IRQ(IRQ_FIMD0_SYSTEM),
> + [1] = DEFINE_RES_IRQ_NAMED(IRQ_FIMD0_VSYNC, "vsync"),
> + [2] = DEFINE_RES_IRQ(IRQ_FIMD0_FIFO, "fifo"),
> + [3] = DEFINE_RES_IRQ(IRQ_FIMD0_SYSTEM, "system"),
> };
>
> struct platform_device s5p_device_fimd0 = {
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 36493ce..5efb4c7 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -917,7 +917,7 @@ static int fimd_probe(struct platform_device *pdev)
> if (IS_ERR(ctx->regs))
> return PTR_ERR(ctx->regs);
>
> - res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> + res = platform_get_resource_byname(pdev, IORESOURCE_IRQ, "vsync");
> if (!res) {
> dev_err(dev, "irq request failed.\n");
> return -ENXIO;
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 968a625..43af0108 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -1427,7 +1427,7 @@ static int s3c_fb_probe(struct platform_device *pdev)
> goto err_lcd_clk;
> }
>
> - res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> + res = platform_get_resource_byname(pdev, IORESOURCE_IRQ, "vsync");
> if (!res) {
> dev_err(dev, "failed to acquire irq resource\n");
> ret = -ENOENT;
--
Thanks and Regards
Vikas Sajjan
--
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 RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver
Thanks Seung Woo, Mr. Dae, On Thu, Mar 7, 2013 at 10:13 AM, Inki Dae wrote: > 2013/3/7 김승우 : >> >> >> On 2013년 03월 04일 23:05, Rahul Sharma wrote: >>> Thanks Sean, >>> >>> On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul wrote: On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma wrote: > Right now hdmiphy operations and configs are kept inside hdmi driver. > hdmiphy related > code is tightly coupled with hdmi ip driver. Physicaly they are different > devices and s/Physicaly/Physically/ > should be instantiated independently. > > In terms of versions/mapping/configurations Hdmi and hdmiphy are > independent of each > other. It is preferred to isolate them and maintained independently. > > This implementations is tested for: > 1) Resolutions supported by exynos4 and 5 hdmi. > 2) Runtime PM and S2R scenarions for exynos5. > I don't like the idea of spawning off yet another driver in here. It adds more globals, more suspend/resume ordering issues, and more implicit dependencies. I understand, however, that this is the Chosen Way for the exynos driver, so I will save my rant. >>> >>> I agree to it. splitting phy to a new driver will complicate the power >>> related >>> scenarios. But in upcoming SoC,s, Phy is changing considerably in terms of >>> config values, mapping (i2c/platform bus) etc. Handling this diversity >>> inside hdmi driver is complicating it with unrelated changes. >> >> Basically, I agree with the idea to split hdmiphy from hdmi. And it >> seems that already existing hdmiphy i2c device is just reused and >> hdmiphy_power_on is reorganized to hdmiphy dpms operation: even calling >> flow of power operations is reordered. >> >> But I'm not sure exynos_hdmiphy_driver_register() really need to be >> called from exynos_drm_init() of exynos_drm_drv.c. IMO, it is enough to >> call exynos_hdmiphy_driver_register() from hdmi_probe() because hdmiphy >> is only used from hdmi. >> > > I agree with Seung-Woo. The hdmiphy is just one part of HDMI subsystem. > I agree to the Seung Woo's point that hdmi-phy used to be solely accessed by hdmi driver. But in this RFC, hdmi-phy is not called by hdmi driver anymore. Phy ops will be called from drm-common-hdmi platform driver along with mixer and hdmi ops. The rational behind my implementation is that I am projecting hdmi-phy as a device which is peer to hdmi ip and mixer. These 3 devices together makes DRM HDMI subsystem. Even physically hdmi-phy doesn't seems to be a part of hdmi ip though configurations are listed under hdmi ip user manual. It looks like a isolated module accessed by i2c. Though I don't find anything wrong with Seung Woo suggestion but above placement of hdmi-phy (parallel to hdmi and mixer) makes more sense to me. Please have a another look at it and let me know your opinion. Another things which bothers me is registering mixer, hdmi driver inside exynos_drm_init(). If we strictly follow the hierarchy inside drm, exynos_drm_init() should register drm-common-hdmi only. drm-common-hdmi should register mixer and hdmi (or hdmi-phy as well). regards, Rahul Sharma. > Thanks, > Inki Dae > >> Thanks and Regards, >> - Seung-Woo Kim >> >>> >>> I have tested this RFC for Runtime PM / S2R. But if we see any major >>> roadblock >>> we should re-factor this by explicitly calling power related callbacks >>> of mixer, phy, >>> hdmi drivers in a required order. We can call them from exynos-drm-hdmi plf >>> device. AFAIR something like this is already in place in chrome-kernel. >>> I've made some comments below. > This patch is dependent on > http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34733.html > http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34861.html > http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34862.html > > Signed-off-by: Rahul Sharma > --- > It is based on exynos-drm-next-todo branch at > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > > drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 + > drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 + > drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 58 ++- > drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 + > drivers/gpu/drm/exynos/exynos_hdmi.c | 375 ++-- > drivers/gpu/drm/exynos/exynos_hdmi.h | 1 - > drivers/gpu/drm/exynos/exynos_hdmiphy.c | 586 > ++- > drivers/gpu/drm/exynos/regs-hdmiphy.h| 61 > 8 files changed, 738 insertions(+), 368 deletions(-) > create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h > >> >> >> >> -- >> Seung-Woo Kim >> Samsung Software R&D Center >> -- >> >> ___ >> dri-devel mailing list >> dri-de...@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Regar
Re: [PATCH] i2c: s3c24xx: allow device core to setup default pin configuration
On Mon, Mar 4, 2013 at 2:42 PM, Thomas Abraham wrote: > With device core now able to setup the default pin configuration, > the call to devm_pinctrl_get_select_default can be removed. And > the pin configuration code based on the deprecated Samsung specific > gpio bindings is also removed. > > Signed-off-by: Thomas Abraham Acked-by: Linus Walleij 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] ARM: SAMSUNG: Set clock parent if provided
s3c_set_clksrc() updates the clock source as per u-boot settings.
This patch adds the functionality to overwrite u-boot settings,
if user provides the clock parent field. In case of wrong source
provided by the user, it will retain the u-boot settings.
Signed-off-by: Shaik Ameer Basha
---
arch/arm/plat-samsung/clock-clksrc.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/plat-samsung/clock-clksrc.c
b/arch/arm/plat-samsung/clock-clksrc.c
index 786a410..4fecd80 100644
--- a/arch/arm/plat-samsung/clock-clksrc.c
+++ b/arch/arm/plat-samsung/clock-clksrc.c
@@ -150,7 +150,12 @@ void __init_or_cpufreq s3c_set_clksrc(struct clksrc_clk
*clk, bool announce)
return;
}
- clk->clk.parent = srcs->sources[clksrc];
+ if (clk->clk.parent) {
+ if (s3c_setparent_clksrc(&clk->clk, clk->clk.parent))
+ clk->clk.parent = srcs->sources[clksrc];
+ } else {
+ clk->clk.parent = srcs->sources[clksrc];
+ }
if (announce)
printk(KERN_INFO "%s: source is %s (%d), rate is %ld\n",
--
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 RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver
2013/3/7 김승우 : > > > On 2013년 03월 04일 23:05, Rahul Sharma wrote: >> Thanks Sean, >> >> On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul wrote: >>> On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma >>> wrote: Right now hdmiphy operations and configs are kept inside hdmi driver. hdmiphy related code is tightly coupled with hdmi ip driver. Physicaly they are different devices and >>> >>> s/Physicaly/Physically/ >>> should be instantiated independently. In terms of versions/mapping/configurations Hdmi and hdmiphy are independent of each other. It is preferred to isolate them and maintained independently. This implementations is tested for: 1) Resolutions supported by exynos4 and 5 hdmi. 2) Runtime PM and S2R scenarions for exynos5. >>> >>> I don't like the idea of spawning off yet another driver in here. It >>> adds more globals, more suspend/resume ordering issues, and more >>> implicit dependencies. I understand, however, that this is the Chosen >>> Way for the exynos driver, so I will save my rant. >>> >> >> I agree to it. splitting phy to a new driver will complicate the power >> related >> scenarios. But in upcoming SoC,s, Phy is changing considerably in terms of >> config values, mapping (i2c/platform bus) etc. Handling this diversity >> inside hdmi driver is complicating it with unrelated changes. > > Basically, I agree with the idea to split hdmiphy from hdmi. And it > seems that already existing hdmiphy i2c device is just reused and > hdmiphy_power_on is reorganized to hdmiphy dpms operation: even calling > flow of power operations is reordered. > > But I'm not sure exynos_hdmiphy_driver_register() really need to be > called from exynos_drm_init() of exynos_drm_drv.c. IMO, it is enough to > call exynos_hdmiphy_driver_register() from hdmi_probe() because hdmiphy > is only used from hdmi. > I agree with Seung-Woo. The hdmiphy is just one part of HDMI subsystem. Thanks, Inki Dae > Thanks and Regards, > - Seung-Woo Kim > >> >> I have tested this RFC for Runtime PM / S2R. But if we see any major >> roadblock >> we should re-factor this by explicitly calling power related callbacks >> of mixer, phy, >> hdmi drivers in a required order. We can call them from exynos-drm-hdmi plf >> device. AFAIR something like this is already in place in chrome-kernel. >> >>> I've made some comments below. >>> This patch is dependent on http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34733.html http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34861.html http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34862.html Signed-off-by: Rahul Sharma --- It is based on exynos-drm-next-todo branch at git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 + drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 + drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 58 ++- drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 + drivers/gpu/drm/exynos/exynos_hdmi.c | 375 ++-- drivers/gpu/drm/exynos/exynos_hdmi.h | 1 - drivers/gpu/drm/exynos/exynos_hdmiphy.c | 586 ++- drivers/gpu/drm/exynos/regs-hdmiphy.h| 61 8 files changed, 738 insertions(+), 368 deletions(-) create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h > > > > -- > Seung-Woo Kim > Samsung Software R&D Center > -- > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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 V3 1/4] cpufreq: exynos: Adding cpufreq driver for exynos5440
This patch adds dvfs support for exynos5440 SOC. This soc has 4 cores and
they scale at same frequency. The nature of exynos5440 clock controller is
different from previous exynos controllers so not using the common exynos
cpufreq framework. The major difference being interrupt notfication for
frequency change. Also, OPP library is used for device tree parsing to get
different parameters like frequency, voltage etc. Since the opp library sorts
the frequency table in ascending order so they are again re-arranged in
descending order. This will have one-to-one mapping with the clock controller
state management logic.
Signed-off-by: Amit Daniel Kachhap
---
Changes in V3:
* Converted the driver to probe based as suggested by Viresh. This is also
beneficial for multiplatform kernel.
* Other coding guidelines related changes.
Changes in V2:
* Added OPP library support to parse DT parameters.
* Removed a hack to handle interrupts in bootup.
* Implemented other review comments from Viresh and Inder.
All these patches are dependent on Thomas Abraham common clock patches.
(http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg15860.html)
This whole patch series is based on 3.9-rc1.
.../bindings/cpufreq/cpufreq-exynos5440.txt| 29 ++
drivers/cpufreq/Kconfig.arm|9 +
drivers/cpufreq/Makefile |1 +
drivers/cpufreq/exynos5440-cpufreq.c | 467
4 files changed, 506 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
create mode 100644 drivers/cpufreq/exynos5440-cpufreq.c
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
new file mode 100644
index 000..a0dbe0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt
@@ -0,0 +1,29 @@
+
+Exynos5440 cpufreq driver
+---
+
+Exynos5440 SoC cpufreq driver for CPU frequency scaling.
+
+Required properties:
+- interrupts: Interrupt to know the completion of cpu frequency change.
+- operating-points: Table of frequencies and voltage CPU could be transitioned
into,
+ in the decreasing order. Frequency should be in KHZ units and voltage
+ should be in microvolts.
+
+Optional properties:
+- clock-latency: Clock monitor latency in microsecond.
+
+All the required listed above must be defined under node cpufreq.
+
+Example:
+
+ cpufreq@16 {
+ compatible = "samsung,exynos5440-cpufreq";
+ reg = <0x16 0x1000>;
+ interrupts = <0 57 0>;
+ operating-points = <
+ 100 975000
+ 80 925000>;
+ clock-latency = <10>;
+ };
+
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 030ddf6..7ed9c4a 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -77,6 +77,15 @@ config ARM_EXYNOS5250_CPUFREQ
This adds the CPUFreq driver for Samsung EXYNOS5250
SoC.
+config ARM_EXYNOS5440_CPUFREQ
+ def_bool SOC_EXYNOS5440
+ depends on HAVE_CLK && PM_OPP && OF
+ help
+ This adds the CPUFreq driver for Samsung EXYNOS5440
+ SoC. The nature of exynos5440 clock controller is
+ different than previous exynos controllers so not using
+ the common exynos framework.
+
config ARM_KIRKWOOD_CPUFREQ
def_bool ARCH_KIRKWOOD && OF
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 863fd18..c841438 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ) += exynos4x12-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ) += exynos5250-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)+= omap-cpufreq.o
obj-$(CONFIG_ARM_SPEAR_CPUFREQ)+= spear-cpufreq.o
diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
b/drivers/cpufreq/exynos5440-cpufreq.c
new file mode 100644
index 000..ea3d46d
--- /dev/null
+++ b/drivers/cpufreq/exynos5440-cpufreq.c
@@ -0,0 +1,467 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Amit Daniel Kachhap
+ *
+ * EXYNOS5440 - CPU frequency scaling support
+ *
+ * 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.
+*/
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
[PATCH V3 2/4] cpufreq: exynos: Remove error return even if no soc is found
This patch helps to have single binary for exynos5440 and previous
exynos soc's. This change is needed for adding exynos5440 cpufreq driver
which does not uses exynos-cpufreq common file and adds it own driver.
Signed-off-by: Amit Daniel Kachhap
---
drivers/cpufreq/exynos-cpufreq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 78057a3..ee75997 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -297,7 +297,7 @@ static int __init exynos_cpufreq_init(void)
else if (soc_is_exynos5250())
ret = exynos5250_cpufreq_init(exynos_info);
else
- pr_err("%s: CPU type not found\n", __func__);
+ return 0;
if (ret)
goto err_vdd_arm;
--
1.7.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
[PATCH V3 3/4] arm: exynos: Enable OPP library support for exynos5440
The OPP library support is needed for exynos5440 cpu frequency dynamic scaling driver. Signed-off-by: Amit Daniel Kachhap --- arch/arm/mach-exynos/Kconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 70f94c8..d5dde07 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -72,10 +72,12 @@ config SOC_EXYNOS5440 bool "SAMSUNG EXYNOS5440" default y depends on ARCH_EXYNOS5 + select ARCH_HAS_OPP select ARM_ARCH_TIMER select AUTO_ZRELADDR select PINCTRL select PINCTRL_EXYNOS5440 + select PM_OPP help Enable EXYNOS5440 SoC support -- 1.7.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
[PATCH V3 4/4] dts: Add cpufreq controller node for Exynos5440 SoC
Add cpufreq controller device node for Exynos5440 SoC for passing
parameters like controller base address, interrupt and cpufreq
table. This node is added outside cpu0 as this driver is now a platform
driver and a new device structure is needed.
Signed-off-by: Amit Daniel Kachhap
---
Changes in V3:
* Moved the DT node outside cpu0 node as the driver is now a platform
driver.
arch/arm/boot/dts/exynos5440.dtsi | 12
arch/arm/mach-exynos/mach-exynos5-dt.c |2 ++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5440.dtsi
b/arch/arm/boot/dts/exynos5440.dtsi
index 5f3562a..4b29a5a 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -63,6 +63,18 @@
};
+ cpufreq@16 {
+ compatible = "samsung,exynos5440-cpufreq";
+ reg = <0x16 0x1000>;
+ interrupts = <0 57 0>;
+ operating-points = <
+ /* KHZuV */
+ 120 1025000
+ 100 975000
+ 80 925000
+ >;
+ };
+
serial@B {
compatible = "samsung,exynos4210-uart";
reg = <0xB 0x1000>;
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index acaeb14..0a446c4 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -145,6 +145,8 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[] __initconst = {
static const struct of_dev_auxdata exynos5440_auxdata_lookup[] __initconst = {
OF_DEV_AUXDATA("samsung,exynos4210-uart", EXYNOS5440_PA_UART0,
"exynos4210-uart.0", NULL),
+ OF_DEV_AUXDATA("samsung,exynos5440-cpufreq", 0x16,
+ "exynos5440-cpufreq", NULL),
{},
};
--
1.7.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 v2 0/7] Add G2D nodes to Exynos4 machines
Hi Kukjin, Can you please look into this series as it is pending since quite some time. On 18 February 2013 10:32, Sachin Kamat wrote: > This patch series is based on Kukjin Kim's next/dt-exynos branch of > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > tree. > > Changes since v1: > * Removed power-domain entry in patch 1/7 as the driver currently > does not use it. > * Addressed review comments from Sylwester Nawrocki and Tomasz Figa > in patch 7/7. > > Sachin Kamat (7): > ARM: dts: Add G2D node to exynos4210.dtsi > ARM: dts: Add G2D node to SMDKV310 > ARM: dts: Add G2D node to exynos4210-origen > ARM: dts: Add G2D node to exynos4x12.dtsi > ARM: dts: Add G2D node to SMDK4412 > ARM: dts: Add G2D node to exynos4412-origen > ARM: dts: Add Samsung G2D DT bindings documentation -- 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 0/3] pinctrl: exynos: add support for Samsung's Exynos5250
Thomas Abraham wrote: > > On 7 March 2013 05:41, Kukjin Kim wrote: > > Thomas Abraham wrote: > >> > >> Changes since v1: > >> - Change the compatible string from "samsung,pinctrl-exynos5250" to > >> "samsung,exynos5250-pinctrl". > >> - Rebased to v3.9-rc1 > >> > > > > Thomas, this stuff is already in my tree for v3.10, and above changes > > included in there. Do you want to replace with this patches? > > Dear Mr. Kim, > > The v2 version includes one fix for the compatilble string. It changes > the compatible string from "samsung,pinctrl-exynos5250" to > "samsung,exynos5250-pinctrl". So could you pick this v2 series instead > of the series which you have already merged. > Hey, probably, you didn't check my tree. As I said, already changed/fixed. - Kukjin -- 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 0/3] pinctrl: exynos: add support for Samsung's Exynos5250
On 7 March 2013 05:41, Kukjin Kim wrote: > Thomas Abraham wrote: >> >> Changes since v1: >> - Change the compatible string from "samsung,pinctrl-exynos5250" to >> "samsung,exynos5250-pinctrl". >> - Rebased to v3.9-rc1 >> > > Thomas, this stuff is already in my tree for v3.10, and above changes > included in there. Do you want to replace with this patches? Dear Mr. Kim, The v2 version includes one fix for the compatilble string. It changes the compatible string from "samsung,pinctrl-exynos5250" to "samsung,exynos5250-pinctrl". So could you pick this v2 series instead of the series which you have already merged. Thanks, Thomas. > > - Kukjin > >> This patch series add pinctrl driver support for Samsung's Exynos5250 SoC. >> The first patch adds the required Exynos5250 SoC specific data which is >> used by the Samsung pinctrl driver to setup the pinctrl/pinmux/eint >> controllers. The second and third patches skips the wakeup interrupt and >> gpiolib registration if the pinctrl support is enabled for Exynos5250. >> >> Thomas Abraham (3): >> pinctrl: exynos: add exynos5250 SoC specific data >> gpio: samsung: skip gpiolib registration if pinctrl support is enabled >> for exynos5250 >> arm: exynos: skip wakeup interrupt registration for exynos5250 if >> pinctrl is enabled >> >> arch/arm/mach-exynos/common.c |1 + >> drivers/gpio/gpio-samsung.c |1 + >> drivers/pinctrl/pinctrl-exynos.c | 108 >> + >> drivers/pinctrl/pinctrl-samsung.c |2 + >> drivers/pinctrl/pinctrl-samsung.h |1 + >> 5 files changed, 113 insertions(+), 0 deletions(-) > -- 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 v2] iio: adc: exynos5_adc: fix compilation warnings
Fixes the compilation warnings and potential NULL pointer
dereferencing pointed out by "Dan Carpenter".
Signed-off-by: Naveen Krishna Ch
Cc: Jonathan Cameron
Cc: Lars-Peter Clausen
Series-to: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Dan Carpenter
---
Changes since v1:
Made the exynos_adc driver depends on CONFIG_OF.
drivers/iio/adc/Kconfig |1 +
drivers/iio/adc/exynos_adc.c | 21 ++---
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index a40d3c2..9c45c0f 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -105,6 +105,7 @@ config AT91_ADC
config EXYNOS_ADC
bool "Exynos ADC driver support"
+ depends on OF
help
Core support for the ADC block found in the Samsung EXYNOS series
of SoCs for drivers such as the touchscreen and hwmon to use to share
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index ed6fdd7..4fd5e3a 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -92,7 +92,7 @@ struct exynos_adc {
struct completion completion;
u32 value;
- unsigned intversion;
+ unsigned intversion;
};
static const struct of_device_id exynos_adc_match[] = {
@@ -102,12 +102,12 @@ static const struct of_device_id exynos_adc_match[] = {
};
MODULE_DEVICE_TABLE(of, exynos_adc_match);
-static inline unsigned int exynos_adc_get_version(struct platform_device *pdev)
+static inline int exynos_adc_get_version(struct platform_device *pdev)
{
const struct of_device_id *match;
match = of_match_node(exynos_adc_match, pdev->dev.of_node);
- return (unsigned int)match->data;
+ return (int)match->data;
}
static int exynos_read_raw(struct iio_dev *indio_dev,
@@ -117,7 +117,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
long mask)
{
struct exynos_adc *info = iio_priv(indio_dev);
- unsigned long timeout;
+ int timeout;
u32 con1, con2;
if (mask != IIO_CHAN_INFO_RAW)
@@ -255,7 +255,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
struct iio_dev *indio_dev = NULL;
struct resource *mem;
int ret = -ENODEV;
- int irq;
+ int irq, version;
if (!np)
return ret;
@@ -268,6 +268,15 @@ static int exynos_adc_probe(struct platform_device *pdev)
info = iio_priv(indio_dev);
+ version = exynos_adc_get_version(pdev);
+ if (version < 0) {
+ dev_err(&pdev->dev, "no matching of_node, err = %d\n", version);
+ ret = version;
+ goto err_iio;
+ }
+
+ info->version = version;
+
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
info->regs = devm_request_and_ioremap(&pdev->dev, mem);
@@ -311,8 +320,6 @@ static int exynos_adc_probe(struct platform_device *pdev)
goto err_irq;
}
- info->version = exynos_adc_get_version(pdev);
-
platform_set_drvdata(pdev, indio_dev);
indio_dev->name = dev_name(&pdev->dev);
--
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 00/23] RFC: exynos multiplatform support
On Wednesday 06 March 2013, Thierry Reding wrote: > > Option 2 would probably come down to having a trivial MFD driver exposing > > a regmap. You can probably reuse drivers/mfd/syscon.c for this and make > > the node compatible with "syscon" to designate the clock registers as > > a system-wide resource, making the other device nodes register-less. > > I think option 2 is the standard method if one hardware block provides > several logical devices. I find it to be a pretty nice solution to this > problem. We also have precedent in the PWM subsystem. The TWL chips for > instance use it to create a platform device which is later driven by a > PWM driver. One difference though is that the TWL chip is a heterogenous MFD that has a lot of different sub-devices, where in case of Exynos the timer device has a set of identical units, each of which can be used either as a PWM or as a clocksource or other timer. 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 RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver
On 2013년 03월 04일 23:05, Rahul Sharma wrote: > Thanks Sean, > > On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul wrote: >> On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma >> wrote: >>> Right now hdmiphy operations and configs are kept inside hdmi driver. >>> hdmiphy related >>> code is tightly coupled with hdmi ip driver. Physicaly they are different >>> devices and >> >> s/Physicaly/Physically/ >> >>> should be instantiated independently. >>> >>> In terms of versions/mapping/configurations Hdmi and hdmiphy are >>> independent of each >>> other. It is preferred to isolate them and maintained independently. >>> >>> This implementations is tested for: >>> 1) Resolutions supported by exynos4 and 5 hdmi. >>> 2) Runtime PM and S2R scenarions for exynos5. >>> >> >> I don't like the idea of spawning off yet another driver in here. It >> adds more globals, more suspend/resume ordering issues, and more >> implicit dependencies. I understand, however, that this is the Chosen >> Way for the exynos driver, so I will save my rant. >> > > I agree to it. splitting phy to a new driver will complicate the power related > scenarios. But in upcoming SoC,s, Phy is changing considerably in terms of > config values, mapping (i2c/platform bus) etc. Handling this diversity > inside hdmi driver is complicating it with unrelated changes. Basically, I agree with the idea to split hdmiphy from hdmi. And it seems that already existing hdmiphy i2c device is just reused and hdmiphy_power_on is reorganized to hdmiphy dpms operation: even calling flow of power operations is reordered. But I'm not sure exynos_hdmiphy_driver_register() really need to be called from exynos_drm_init() of exynos_drm_drv.c. IMO, it is enough to call exynos_hdmiphy_driver_register() from hdmi_probe() because hdmiphy is only used from hdmi. Thanks and Regards, - Seung-Woo Kim > > I have tested this RFC for Runtime PM / S2R. But if we see any major roadblock > we should re-factor this by explicitly calling power related callbacks > of mixer, phy, > hdmi drivers in a required order. We can call them from exynos-drm-hdmi plf > device. AFAIR something like this is already in place in chrome-kernel. > >> I've made some comments below. >> >>> This patch is dependent on >>> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34733.html >>> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34861.html >>> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg34862.html >>> >>> Signed-off-by: Rahul Sharma >>> --- >>> It is based on exynos-drm-next-todo branch at >>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git >>> >>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 + >>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 + >>> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 58 ++- >>> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 + >>> drivers/gpu/drm/exynos/exynos_hdmi.c | 375 ++-- >>> drivers/gpu/drm/exynos/exynos_hdmi.h | 1 - >>> drivers/gpu/drm/exynos/exynos_hdmiphy.c | 586 >>> ++- >>> drivers/gpu/drm/exynos/regs-hdmiphy.h| 61 >>> 8 files changed, 738 insertions(+), 368 deletions(-) >>> create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h >>> -- Seung-Woo Kim Samsung Software R&D Center -- -- 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
[GIT PULL 5/5] Samsung pinctrl-exynos5250 for v3.10
Arnd, Olof, Here is support pinctrl-exynos5250 and that already got ack from Linus Walliej. If any problems, please let me know. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8: Linux 3.9-rc1 (2013-03-03 15:11:05 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git next/pinctrl-exynos for you to fetch changes up to 97916777d6904e24b86eac77da58ef7cb09d539d: ARM: EXYNOS: skip wakeup interrupt registration for exynos5250 if pinctrl is enabled (2013-03-05 20:59:12 +0900) Thomas Abraham (3): pinctrl: exynos: add exynos5250 SoC specific data gpio: samsung: skip gpiolib registration if pinctrl support is enabled for exynos5250 ARM: EXYNOS: skip wakeup interrupt registration for exynos5250 if pinctrl is enabled arch/arm/mach-exynos/common.c |1 + drivers/gpio/gpio-samsung.c |1 + drivers/pinctrl/pinctrl-exynos.c | 108 + drivers/pinctrl/pinctrl-samsung.c |2 + drivers/pinctrl/pinctrl-samsung.h |1 + 5 files changed, 113 insertions(+) -- 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
[GIT PULL 4/5] Samsung irq-s3c24xx for v3.10
Arnd, Olof, Here is finish the irq rework for s3c2412, s3c2440 and s3c2442 into the new structure and eint0 to 3 on the s3c2412. If any problems, please let me know. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. The following changes since commit ad38bdd15d5b97dcb1ffc46ea77c237e30312fbb: ARM: SAMSUNG: Remove unused plat-samsung/time.c (2013-03-05 20:19:54 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git next/irq-s3c24xx for you to fetch changes up to d97fedef912832611b668fa7ece8e8ff54a6a590: gpio: samsung: fixes build warning with s3c2410_defconfig (2013-03-05 20:21:36 +0900) Heiko Stuebner (13): ARM: S3C24XX: move s3c244x irq init to common irq code ARM: S3C24XX: create dedicated irq init functions for s3c2440 and s3c2442 ARM: S3C24XX: move s3c2440 irqs to common irq code ARM: S3C24XX: integrate s3c2440 irqs into common init ARM: S3C24XX: transform s3c2442 irqs into new structure ARM: S3C24XX: transform s3c2440 irqs into new structure ARM: S3C24XX: use samsung_sync_wakemask in s3c2412 pm ARM: S3C24XX: move s3c2412 irq init to common code ARM: S3C24XX: modify s3c2412 irq init to initialize all irqs ARM: S3C24XX: transform s3c2412 irqs into new structure ARM: S3C24XX: include first 4 bits of the eint register in irq mapping ARM: S3C24XX: add soc_is_s3c2412 option ARM: S3C24XX: handle s3c2412 eints using new infrastructure Kukjin Kim (1): gpio: samsung: fixes build warning with s3c2410_defconfig arch/arm/mach-s3c24xx/Kconfig |1 + arch/arm/mach-s3c24xx/Makefile|6 +- arch/arm/mach-s3c24xx/common.h|3 + arch/arm/mach-s3c24xx/include/mach/irqs.h | 58 --- arch/arm/mach-s3c24xx/irq-s3c2412.c | 215 --- arch/arm/mach-s3c24xx/irq-s3c2440.c | 128 -- arch/arm/mach-s3c24xx/irq-s3c244x.c | 142 arch/arm/mach-s3c24xx/irq.c | 264 - arch/arm/mach-s3c24xx/mach-anubis.c |2 +- arch/arm/mach-s3c24xx/mach-at2440evb.c|2 +- arch/arm/mach-s3c24xx/mach-gta02.c|2 +- arch/arm/mach-s3c24xx/mach-jive.c |2 +- arch/arm/mach-s3c24xx/mach-mini2440.c |2 +- arch/arm/mach-s3c24xx/mach-nexcoder.c |2 +- arch/arm/mach-s3c24xx/mach-osiris.c |2 +- arch/arm/mach-s3c24xx/mach-rx1950.c |2 +- arch/arm/mach-s3c24xx/mach-rx3715.c |7 +- arch/arm/mach-s3c24xx/mach-smdk2413.c |6 +- arch/arm/mach-s3c24xx/mach-smdk2440.c |2 +- arch/arm/mach-s3c24xx/mach-vstms.c|2 +- arch/arm/mach-s3c24xx/pm-s3c2412.c|8 + arch/arm/plat-samsung/include/plat/cpu.h | 10 ++ drivers/gpio/gpio-samsung.c |8 +- 23 files changed, 332 insertions(+), 544 deletions(-) delete mode 100644 arch/arm/mach-s3c24xx/irq-s3c2412.c delete mode 100644 arch/arm/mach-s3c24xx/irq-s3c2440.c delete mode 100644 arch/arm/mach-s3c24xx/irq-s3c244x.c -- 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
[GIT PULL 3/5] Samsung timer for v3.10
Arnd, Olof,
Here is re-work samsung-time which was s5p-time to support
clocksource/clockevent API for s3c and s5pc100 timer driver. And this enables to
support high resolution timer and tickles mode on them.
Note, this depends on previous pull request (cleanup-s3c) because of touching
while s3c stuff.
If any problems, please let me know.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
The following changes since commit 7488335dcf382574c47fb27fcbad3f04a9841db6:
ARM: S3C24XX: cleanup the included soc init functions in common.h (2013-03-05
10:42:48 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
next/timer-samsung
for you to fetch changes up to ad38bdd15d5b97dcb1ffc46ea77c237e30312fbb:
ARM: SAMSUNG: Remove unused plat-samsung/time.c (2013-03-05 20:19:54 +0900)
Romain Naour (5):
ARM: SAMSUNG: Rename s5p-time to samsung-time
ARM: S3C24XX: Add samsung-time support for s3c24xx
ARM: S3C64XX: Add samsung-time support for s3c64xx
ARM: S5PC100: Add samsung-time support for s5pc100
ARM: SAMSUNG: Remove unused plat-samsung/time.c
arch/arm/Kconfig | 11 +-
arch/arm/mach-exynos/Kconfig |2 +-
arch/arm/mach-exynos/mach-universal_c210.c |6 +-
arch/arm/mach-s3c24xx/Kconfig |6 +
arch/arm/mach-s3c24xx/mach-amlm5900.c |5 +-
arch/arm/mach-s3c24xx/mach-anubis.c|4 +-
arch/arm/mach-s3c24xx/mach-at2440evb.c |4 +-
arch/arm/mach-s3c24xx/mach-bast.c |4 +-
arch/arm/mach-s3c24xx/mach-gta02.c |4 +-
arch/arm/mach-s3c24xx/mach-h1940.c |5 +-
arch/arm/mach-s3c24xx/mach-jive.c |4 +-
arch/arm/mach-s3c24xx/mach-mini2440.c |4 +-
arch/arm/mach-s3c24xx/mach-n30.c |6 +-
arch/arm/mach-s3c24xx/mach-nexcoder.c |4 +-
arch/arm/mach-s3c24xx/mach-osiris.c|4 +-
arch/arm/mach-s3c24xx/mach-otom.c |4 +-
arch/arm/mach-s3c24xx/mach-qt2410.c|4 +-
arch/arm/mach-s3c24xx/mach-rx1950.c|4 +-
arch/arm/mach-s3c24xx/mach-rx3715.c|4 +-
arch/arm/mach-s3c24xx/mach-smdk2410.c |4 +-
arch/arm/mach-s3c24xx/mach-smdk2413.c |8 +-
arch/arm/mach-s3c24xx/mach-smdk2416.c |4 +-
arch/arm/mach-s3c24xx/mach-smdk2440.c |4 +-
arch/arm/mach-s3c24xx/mach-smdk2443.c |4 +-
arch/arm/mach-s3c24xx/mach-tct_hammer.c|4 +-
arch/arm/mach-s3c24xx/mach-vr1000.c|4 +-
arch/arm/mach-s3c24xx/mach-vstms.c |4 +-
arch/arm/mach-s3c64xx/Kconfig |2 +
arch/arm/mach-s3c64xx/mach-anw6410.c |4 +-
arch/arm/mach-s3c64xx/mach-crag6410.c |4 +-
arch/arm/mach-s3c64xx/mach-hmt.c |4 +-
arch/arm/mach-s3c64xx/mach-mini6410.c |4 +-
arch/arm/mach-s3c64xx/mach-ncp.c |4 +-
arch/arm/mach-s3c64xx/mach-real6410.c |4 +-
arch/arm/mach-s3c64xx/mach-smartq.c|2 +
arch/arm/mach-s3c64xx/mach-smartq5.c |3 +-
arch/arm/mach-s3c64xx/mach-smartq7.c |3 +-
arch/arm/mach-s3c64xx/mach-smdk6400.c |4 +-
arch/arm/mach-s3c64xx/mach-smdk6410.c |4 +-
arch/arm/mach-s5p64x0/Kconfig |4 +-
arch/arm/mach-s5p64x0/mach-smdk6440.c |6 +-
arch/arm/mach-s5p64x0/mach-smdk6450.c |6 +-
arch/arm/mach-s5pc100/Kconfig |1 +
arch/arm/mach-s5pc100/mach-smdkc100.c |4 +-
arch/arm/mach-s5pv210/Kconfig |2 +-
arch/arm/mach-s5pv210/mach-aquila.c|6 +-
arch/arm/mach-s5pv210/mach-goni.c |6 +-
arch/arm/mach-s5pv210/mach-smdkc110.c |6 +-
arch/arm/mach-s5pv210/mach-smdkv210.c |6 +-
arch/arm/mach-s5pv210/mach-torbreck.c |6 +-
arch/arm/plat-samsung/Kconfig |2 +-
arch/arm/plat-samsung/Makefile |3 +-
arch/arm/plat-samsung/include/plat/cpu.h |4 -
arch/arm/plat-samsung/include/plat/s5p-time.h | 40 ---
arch/arm/plat-samsung/include/plat/samsung-time.h | 53
.../plat-samsung/{s5p-time.c => samsung-time.c}| 138 +-
arch/arm/plat-samsung/time.c | 287
57 files changed, 275 insertions(+), 472 deletions(-)
delete mode 100644 arch/arm/plat-samsung/include/plat/s5p-time.h
create mode 100644 a
[GIT PULL 1/5] Samsung cleanup-s3c for v3.10
Hi Arnd, Olof,
Here is cleanup for s3c stuff.
This is including cleanup soc specific header files and plat/irqs.h.
If any problems, please let me know.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:
Linux 3.9-rc1 (2013-03-03 15:11:05 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
next/cleanup-s3c
for you to fetch changes up to 7488335dcf382574c47fb27fcbad3f04a9841db6:
ARM: S3C24XX: cleanup the included soc init functions in common.h (2013-03-05
10:42:48 +0900)
Heiko Stuebner (3):
ARM: S3C24XX: remove plat/irq.h in plat-samsung
ARM: S3C24XX: move plat-samsung/s3c24XX headers to local common.h
ARM: S3C24XX: cleanup the included soc init functions in common.h
Kukjin Kim (2):
mmc: s3cmci: moved mach/regs-sdi.h into s3cmci device driver
ARM: S3C24XX: plat/common-smdk.h local
arch/arm/mach-s3c24xx/bast-irq.c |2 -
arch/arm/mach-s3c24xx/clock-s3c2410.c |1 -
arch/arm/mach-s3c24xx/clock-s3c2412.c |1 -
arch/arm/mach-s3c24xx/clock-s3c2416.c |1 -
arch/arm/mach-s3c24xx/clock-s3c2443.c |1 -
arch/arm/mach-s3c24xx/common-smdk.c|3 +-
.../include/plat => mach-s3c24xx}/common-smdk.h|3 +-
arch/arm/mach-s3c24xx/common.c |7 +-
arch/arm/mach-s3c24xx/common.h | 90 +-
arch/arm/mach-s3c24xx/dma-s3c2410.c|1 -
arch/arm/mach-s3c24xx/dma-s3c2412.c|1 -
arch/arm/mach-s3c24xx/dma-s3c2440.c|1 -
arch/arm/mach-s3c24xx/dma-s3c2443.c|1 -
arch/arm/mach-s3c24xx/include/mach/regs-sdi.h | 127
arch/arm/mach-s3c24xx/irq-pm.c |7 +-
arch/arm/mach-s3c24xx/irq.c|8 +-
arch/arm/mach-s3c24xx/mach-jive.c |2 +-
arch/arm/mach-s3c24xx/mach-n30.c |1 -
arch/arm/mach-s3c24xx/mach-nexcoder.c |2 -
arch/arm/mach-s3c24xx/mach-otom.c |1 -
arch/arm/mach-s3c24xx/mach-qt2410.c|2 +-
arch/arm/mach-s3c24xx/mach-smdk2410.c |3 +-
arch/arm/mach-s3c24xx/mach-smdk2413.c |5 +-
arch/arm/mach-s3c24xx/mach-smdk2416.c |4 +-
arch/arm/mach-s3c24xx/mach-smdk2440.c |5 +-
arch/arm/mach-s3c24xx/mach-smdk2443.c |5 +-
arch/arm/mach-s3c24xx/mach-vstms.c |3 +-
arch/arm/mach-s3c24xx/pm-s3c2412.c |1 -
arch/arm/mach-s3c24xx/s3c2410.c|1 -
arch/arm/mach-s3c24xx/s3c2412.c|1 -
arch/arm/mach-s3c24xx/s3c2416.c|1 -
arch/arm/mach-s3c24xx/s3c2440.c|1 -
arch/arm/mach-s3c24xx/s3c2442.c|1 -
arch/arm/mach-s3c24xx/s3c2443.c|1 -
arch/arm/mach-s3c24xx/s3c244x.c|2 -
arch/arm/plat-samsung/include/plat/irq.h | 116 --
arch/arm/plat-samsung/include/plat/s3c2410.h | 31 -
arch/arm/plat-samsung/include/plat/s3c2412.h | 32 -
arch/arm/plat-samsung/include/plat/s3c2416.h | 37 --
arch/arm/plat-samsung/include/plat/s3c2443.h | 36 --
arch/arm/plat-samsung/include/plat/s3c244x.h | 42 ---
drivers/mmc/host/s3cmci.c | 83 -
42 files changed, 194 insertions(+), 480 deletions(-)
rename arch/arm/{plat-samsung/include/plat => mach-s3c24xx}/common-smdk.h (86%)
delete mode 100644 arch/arm/mach-s3c24xx/include/mach/regs-sdi.h
delete mode 100644 arch/arm/plat-samsung/include/plat/irq.h
delete mode 100644 arch/arm/plat-samsung/include/plat/s3c2410.h
delete mode 100644 arch/arm/plat-samsung/include/plat/s3c2412.h
delete mode 100644 arch/arm/plat-samsung/include/plat/s3c2416.h
delete mode 100644 arch/arm/plat-samsung/include/plat/s3c2443.h
delete mode 100644 arch/arm/plat-samsung/include/plat/s3c244x.h
--
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
[GIT PULL 2/5] Samsung cleanup-s5p for v3.10
Arnd, Olof, Here is small cleanup for s5p stuff. This is including useless ifdef. If any problems, please let me know. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8: Linux 3.9-rc1 (2013-03-03 15:11:05 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git next/cleanup-s5p for you to fetch changes up to eb50cd0b2a083950457bf68241a9f040972b6908: ARM: S5PV210: remove useless ifdef in common.h (2013-03-05 18:37:10 +0900) Kukjin Kim (2): ARM: S5PC100: remove useless ifdef in common.h ARM: S5PV210: remove useless ifdef in common.h arch/arm/mach-s5pc100/common.h |9 - arch/arm/mach-s5pv210/common.h |9 - 2 files changed, 18 deletions(-) -- 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
[GIT PULL 0/5] Samsung changes-1 for v3.10
Hi Arnd and Olof, Here is 1st Samsung pull-request for v3.10 This is including cleanup some header files for s3c and s5p, and samsung-timer for s3c and s5pc100 to support clocksource/clockevent api, and irq-rework for s3cs4xx stuff, and support pinctrl for exynos5250. Note, you know, there are some branches in samsung tree I missed to send to upstream last time. I'm sorting them out and as I talked to Olof before, I will send them in early time. If any problems, please kindly let me know. Following is state of whole changes for this pull-requset. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8: Linux 3.9-rc1 (2013-03-03 15:11:05 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for-next for you to fetch changes up to d22d20e4222bc54a28e603de9ad28828bcaad812: Merge branch 'next/pinctrl-exynos' into for-next (2013-03-05 20:59:27 +0900) Heiko Stuebner (16): ARM: S3C24XX: remove plat/irq.h in plat-samsung ARM: S3C24XX: move plat-samsung/s3c24XX headers to local common.h ARM: S3C24XX: cleanup the included soc init functions in common.h ARM: S3C24XX: move s3c244x irq init to common irq code ARM: S3C24XX: create dedicated irq init functions for s3c2440 and s3c2442 ARM: S3C24XX: move s3c2440 irqs to common irq code ARM: S3C24XX: integrate s3c2440 irqs into common init ARM: S3C24XX: transform s3c2442 irqs into new structure ARM: S3C24XX: transform s3c2440 irqs into new structure ARM: S3C24XX: use samsung_sync_wakemask in s3c2412 pm ARM: S3C24XX: move s3c2412 irq init to common code ARM: S3C24XX: modify s3c2412 irq init to initialize all irqs ARM: S3C24XX: transform s3c2412 irqs into new structure ARM: S3C24XX: include first 4 bits of the eint register in irq mapping ARM: S3C24XX: add soc_is_s3c2412 option ARM: S3C24XX: handle s3c2412 eints using new infrastructure Kukjin Kim (11): mmc: s3cmci: moved mach/regs-sdi.h into s3cmci device driver ARM: S3C24XX: plat/common-smdk.h local ARM: dts: cleanup exynos5440.dtsi ARM: S5PC100: remove useless ifdef in common.h ARM: S5PV210: remove useless ifdef in common.h Merge branch 'next/cleanup-s3c' into for-next Merge branch 'next/cleanup-s5p' into for-next gpio: samsung: fixes build warning with s3c2410_defconfig Merge branch 'next/timer-samsung' into for-next Merge branch 'next/irq-s3c24xx' into for-next Merge branch 'next/pinctrl-exynos' into for-next Romain Naour (5): ARM: SAMSUNG: Rename s5p-time to samsung-time ARM: S3C24XX: Add samsung-time support for s3c24xx ARM: S3C64XX: Add samsung-time support for s3c64xx ARM: S5PC100: Add samsung-time support for s5pc100 ARM: SAMSUNG: Remove unused plat-samsung/time.c Thomas Abraham (3): pinctrl: exynos: add exynos5250 SoC specific data gpio: samsung: skip gpiolib registration if pinctrl support is enabled for exynos5250 ARM: EXYNOS: skip wakeup interrupt registration for exynos5250 if pinctrl is enabled arch/arm/Kconfig | 11 +- arch/arm/boot/dts/exynos5440.dtsi |5 - arch/arm/mach-exynos/Kconfig |2 +- arch/arm/mach-exynos/common.c |1 + arch/arm/mach-exynos/mach-universal_c210.c |6 +- arch/arm/mach-s3c24xx/Kconfig |7 + arch/arm/mach-s3c24xx/Makefile |6 +- arch/arm/mach-s3c24xx/bast-irq.c |2 - arch/arm/mach-s3c24xx/clock-s3c2410.c |1 - arch/arm/mach-s3c24xx/clock-s3c2412.c |1 - arch/arm/mach-s3c24xx/clock-s3c2416.c |1 - arch/arm/mach-s3c24xx/clock-s3c2443.c |1 - arch/arm/mach-s3c24xx/common-smdk.c|3 +- .../include/plat => mach-s3c24xx}/common-smdk.h|3 +- arch/arm/mach-s3c24xx/common.c |7 +- arch/arm/mach-s3c24xx/common.h | 93 ++- arch/arm/mach-s3c24xx/dma-s3c2410.c|1 - arch/arm/mach-s3c24xx/dma-s3c2412.c|1 - arch/arm/mach-s3c24xx/dma-s3c2440.c|1 - arch/arm/mach-s3c24xx/dma-s3c2443.c|1 - arch/arm/mach-s3c24xx/include/mach/irqs.h | 58 ++-- arch/arm/mach-s3c24xx/include/mach/regs-sdi.h | 127 - arch/arm/mach-s3c24xx/irq-pm.c |7 +- arch/arm/mach-s3c24xx/irq-s3c2412.c| 215 --- arch/arm/mach-s3c24xx/irq-s3c2440.c| 128 - arch/arm/mach-s3c24xx/irq-s3c244x.c| 142 -- arch/arm/
RE: [PATCH v6 01/16] clk: samsung: add common clock framework helper functions for Samsung platforms
Tomasz Figa wrote: > > Hi, > > On Sunday 03 of March 2013 12:17:29 Sylwester Nawrocki wrote: > > Hi, > > > > On 03/03/2013 02:08 AM, Heiko Stübner wrote: > > > But is there an easy way to define more than one alias? On the s3c2416 > > > for example the hsmmc hclk is the "hsmmc" io-clock, as well as the > > > source for the "mmc_busclk.0". Same for the "uart" pclk, that is also > > > a baud clock source. > > This driver currently provides for only one additional clkdev lookup > > entry per a platform clock. I pointed out this desing issue in the > > early version of the patch set. It's because a machine clock definition > > is coupled with a clock consumer definition. And IMO various > > samsung_clock_register_* functions should not have > > clk_register_clkdev() inside them. I.e. first step could be registering > > all machine clocks and in the second one clkdev lookup entries could be > > created. This is how most (all?) existing SoC clock drivers are > > working. > > > > But those multiple aliases are important only for machines with device > > tree support, aren't they ? > > I suppose you meant _without_ device tree support, right? > > > I hope this patch series gets merged early to linux-next in the 3.10 > > cycle so the multiple accumulated fixup patches for this clock driver > > can be merged as well and issues like that you pointed out can be > > resolved with incremental patches. > > Yes, I hope so too. > Yes, I will in this weekend. Note, I will modify [07/16] for universal_c210 as per Kyungmin's request, I'm not sure about universal_c210 though. Thanks. - Kukjin -- 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/2] ARM: exynos: pl330: Add #dma-cells for generic dma binding support
Padma Venkat wrote: > > On Wed, Mar 6, 2013 at 4:07 AM, Arnd Bergmann wrote: > > On Monday 04 March 2013, Padmavathi Venna wrote: > >> > >> This patch adds #dma-cells property to PL330 DMA controller > >> nodes for supporting generic dma dt bindings on samsung exynos > >> platforms. #dma-channels and #dma-requests are not required now > >> but added in advance. > >> > >> Signed-off-by: Padmavathi Venna > > > > Acked-by: Arnd Bergmann > > > > Should we apply these directly to the arm-soc fixes branch, or wait > > until they come back from the Samsung subarchitecture tree? > > Hmm, If Kukjin can take in 3.9 rc2 it's better to go via Samsung tree. > > Kukjin, > > Can you please take this patch in 3.9 rc2 ? > Sure, I will. BTW, Arnd, I'm not sure second one(socfpga.dtsi) can be handled in samsung tree. Thanks. - Kukjin -- 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/2] ARM: EXYNOS: Add PCIe driver support
Thomas Petazzoni wrote: > > Dear Thomas Abraham, > > On Mon, 4 Mar 2013 16:01:59 +0530, Thomas Abraham wrote: > > On 4 March 2013 15:52, Jingoo Han wrote: > > > Exynos5440 has two PCIe controllers which can be used as Root Complex. > > > This driver supports the PCIe controllers as Root Complex mode. > > > > > > Signed-off-by: Surendranath Gurivireddy Balla > > > > Signed-off-by: Siva Reddy Kallam > > > Signed-off-by: Jingoo Han > > > --- > > > .../devicetree/bindings/pci/exynos-pcie.txt| 58 ++ > > > arch/arm/Kconfig |2 + > > > arch/arm/mach-exynos/Kconfig |8 + > > > arch/arm/mach-exynos/Makefile |2 + > > > arch/arm/mach-exynos/include/mach/pcie.h | 146 +++ > > > arch/arm/mach-exynos/pcie.c| 1009 > > > > > Is there any reason to place this code in arch/arm/...? As you know, > > there is a constant effort to relocate as much code as possible from > > arch/arm/mach-exynos. So there must be a strong justification for > > keeping this code in arch/arm/mach-exynos. > > Indeed. Thierry Reding (doing the Tegra PCIe driver) and myself (doing > the Marvell PCIe driver) are putting our drivers in drivers/pci/host/, > in agreement with the PCI maintainers. > I agree. Jingoo, please move this stuff into drivers/pci when you address comments. Thanks. - Kukjin -- 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: drop "select MACH_N35"
Russell King - ARM Linux wrote: > > On Thu, Mar 07, 2013 at 09:50:17AM +0900, Kukjin Kim wrote: > > Paul Bolle wrote: > > > > > > On Thu, 2013-03-07 at 09:02 +0900, Kukjin Kim wrote: > > > > > > > BTW, so the machine type can be removed at arch/arm/tools/mach-types > as > > > well. > > > > > > Well, that file has a big comment on top, containing the line: > > > Please do not send patches to this file; it is automatically > > > generated! > > > > > > So I didn't dare to touch it. > > > > > Yeah, I know. > > > > It will be handled by Russell King :-) > > And deleting entries from it is pointless if they've ever been in the > kernel. OK, I see and agree. Thanks. - Kukjin -- 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: remove EXYNOS_DEV_SYSMMU entirely
Paul Bolle wrote:
>
> Commit 25e9d28d927d2e1731df53f60cde53d75bcb7c36 ("ARM: EXYNOS: remove
> system mmu initialization from exynos tree") removed the Kconfig symbol
> EXYNOS_DEV_SYSMMU. Remove its last traces too.
>
> Signed-off-by: Paul Bolle
> ---
> 0) Untested.
>
> 1) Please note that this patch changes the dependencies of EXYNOS_IOMMU
> (it removed a dependency that could never be met). That's probably what
> needs to be done but some specific review is needed here.
>
> arch/arm/mach-exynos/Kconfig | 4
> drivers/iommu/Kconfig| 2 +-
> 2 files changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 70f94c8..6c2bdc3 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -200,7 +200,6 @@ config MACH_SMDKV310
> select EXYNOS4_SETUP_USB_PHY
> select EXYNOS_DEV_DMA
> select EXYNOS_DEV_DRM
> - select EXYNOS_DEV_SYSMMU
> select S3C24XX_PWM
> select S3C_DEV_HSMMC
> select S3C_DEV_HSMMC1
> @@ -254,7 +253,6 @@ config MACH_UNIVERSAL_C210
> select EXYNOS4_SETUP_USB_PHY
> select EXYNOS_DEV_DMA
> select EXYNOS_DEV_DRM
> - select EXYNOS_DEV_SYSMMU
> select HAVE_SCHED_CLOCK
> select S3C_DEV_HSMMC
> select S3C_DEV_HSMMC2
> @@ -331,7 +329,6 @@ config MACH_ORIGEN
> select EXYNOS4_SETUP_USB_PHY
> select EXYNOS_DEV_DMA
> select EXYNOS_DEV_DRM
> - select EXYNOS_DEV_SYSMMU
> select S3C24XX_PWM
> select S3C_DEV_HSMMC
> select S3C_DEV_HSMMC2
> @@ -367,7 +364,6 @@ config MACH_SMDK4212
> select EXYNOS4_SETUP_USB_PHY
> select EXYNOS_DEV_DMA
> select EXYNOS_DEV_DRM
> - select EXYNOS_DEV_SYSMMU
> select S3C24XX_PWM
> select S3C_DEV_HSMMC2
> select S3C_DEV_HSMMC3
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 5c514d07..c520c20 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -168,7 +168,7 @@ config TEGRA_IOMMU_SMMU
>
> config EXYNOS_IOMMU
> bool "Exynos IOMMU Support"
> - depends on ARCH_EXYNOS && EXYNOS_DEV_SYSMMU
> + depends on ARCH_EXYNOS
> select IOMMU_API
> help
> Support for the IOMMU(System MMU) of Samsung Exynos application
> --
> 1.7.11.7
Actually, to update iommu for exynos is on-going. And as I know, it will be
done this time for v3.10 by KyongHo Cho, so it would be better to handle this
cleanup with that at the same time.
Thanks.
- Kukjin
--
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: change HAVE_SAMSUNG_KEYPAD to KEYBOARD_SAMSUNG
Paul Bolle wrote:
>
> Commit 6b5ab4f442e32f248b6fad29aafd1d5153f4dbd3 ("ARM: EXYNOS: Add
> Exynos4 device tree enabled board file") added
> select HAVE_SAMSUNG_KEYPAD if INPUT_KEYBOARD
>
> to the MACH_EXYNOS4_DT Kconfig entry. But there's no Kconfig symbol
> HAVE_SAMSUNG_KEYPAD. Since this select statement depends on
> INPUT_KEYBOARD this entry should select KEYBOARD_SAMSUNG instead.
>
> Signed-off-by: Paul Bolle
> ---
> 0) Tested with "git grep" only.
>
> 1) Perhaps the fact that the symbol KEYBOARD_SAMSUNG enables a driver
> called samsung-keypad caused confusion here. Anyhow, my choice for
> KEYBOARD_SAMSUNG is only educated guesswork.
>
> arch/arm/mach-exynos/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 6c2bdc3..068aeb5 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -403,7 +403,7 @@ config MACH_EXYNOS4_DT
> depends on ARCH_EXYNOS4
> select ARM_AMBA
> select CPU_EXYNOS4210
> - select HAVE_SAMSUNG_KEYPAD if INPUT_KEYBOARD
> + select KEYBOARD_SAMSUNG if INPUT_KEYBOARD
> select PINCTRL
> select PINCTRL_EXYNOS
> select USE_OF
> --
> 1.7.11.7
Looks good to me, applied.
BTW, just to use only 8~12 digits of commit ID, "Commit 6b5ab4f4" is enough
instead of full commit ID.
Thanks.
- Kukjin
--
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: drop "select MACH_N35"
On Thu, Mar 07, 2013 at 09:50:17AM +0900, Kukjin Kim wrote: > Paul Bolle wrote: > > > > On Thu, 2013-03-07 at 09:02 +0900, Kukjin Kim wrote: > > > > > BTW, so the machine type can be removed at arch/arm/tools/mach-types as > > well. > > > > Well, that file has a big comment on top, containing the line: > > Please do not send patches to this file; it is automatically > > generated! > > > > So I didn't dare to touch it. > > > Yeah, I know. > > It will be handled by Russell King :-) And deleting entries from it is pointless if they've ever been in the kernel. -- 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: drop "select MACH_N35"
Paul Bolle wrote: > > On Thu, 2013-03-07 at 09:02 +0900, Kukjin Kim wrote: > > > BTW, so the machine type can be removed at arch/arm/tools/mach-types as > well. > > Well, that file has a big comment on top, containing the line: > Please do not send patches to this file; it is automatically > generated! > > So I didn't dare to touch it. > Yeah, I know. It will be handled by Russell King :-) Thanks. - Kukjin -- 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: drop "select HAVE_SCHED_CLOCK"
Paul Bolle wrote:
>
> The Kconfig symbol HAVE_SCHED_CLOCK got removed in v3.4, with commit
> 6905a65879b51d326396e63dfea40861a30bc17f ("ARM: Make the sched_clock
> framework mandatory"). Drop the last two select statements for that
> symbol too. They're useless now.
>
> Signed-off-by: Paul Bolle
> ---
> Tested with "git grep" only.
>
> arch/arm/Kconfig | 1 -
> arch/arm/mach-exynos/Kconfig | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 0c990b7..2530799 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1172,7 +1172,6 @@ config PLAT_VERSATILE
> config ARM_TIMER_SP804
> bool
> select CLKSRC_MMIO
> - select HAVE_SCHED_CLOCK
>
> source arch/arm/mm/Kconfig
>
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 068aeb5..acfdbcf 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -253,7 +253,6 @@ config MACH_UNIVERSAL_C210
> select EXYNOS4_SETUP_USB_PHY
> select EXYNOS_DEV_DMA
> select EXYNOS_DEV_DRM
> - select HAVE_SCHED_CLOCK
> select S3C_DEV_HSMMC
> select S3C_DEV_HSMMC2
> select S3C_DEV_HSMMC3
> --
> 1.7.11.7
Right, applied.
Thanks.
- Kukjin
--
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 0/3] pinctrl: exynos: add support for Samsung's Exynos5250
Thomas Abraham wrote: > > Changes since v1: > - Change the compatible string from "samsung,pinctrl-exynos5250" to > "samsung,exynos5250-pinctrl". > - Rebased to v3.9-rc1 > Thomas, this stuff is already in my tree for v3.10, and above changes included in there. Do you want to replace with this patches? - Kukjin > This patch series add pinctrl driver support for Samsung's Exynos5250 SoC. > The first patch adds the required Exynos5250 SoC specific data which is > used by the Samsung pinctrl driver to setup the pinctrl/pinmux/eint > controllers. The second and third patches skips the wakeup interrupt and > gpiolib registration if the pinctrl support is enabled for Exynos5250. > > Thomas Abraham (3): > pinctrl: exynos: add exynos5250 SoC specific data > gpio: samsung: skip gpiolib registration if pinctrl support is enabled > for exynos5250 > arm: exynos: skip wakeup interrupt registration for exynos5250 if > pinctrl is enabled > > arch/arm/mach-exynos/common.c |1 + > drivers/gpio/gpio-samsung.c |1 + > drivers/pinctrl/pinctrl-exynos.c | 108 > + > drivers/pinctrl/pinctrl-samsung.c |2 + > drivers/pinctrl/pinctrl-samsung.h |1 + > 5 files changed, 113 insertions(+), 0 deletions(-) -- 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: drop "select MACH_N35"
On Thu, 2013-03-07 at 09:02 +0900, Kukjin Kim wrote: > BTW, so the machine type can be removed at arch/arm/tools/mach-types as well. Well, that file has a big comment on top, containing the line: Please do not send patches to this file; it is automatically generated! So I didn't dare to touch it. Paul Bolle -- 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: drop "select MACH_N35"
Paul Bolle wrote:
>
> The unused Kconfig symbol MACH_N35 was removed in commit
> 85fd6d63bf2927b9da7ab1b0d46723bfdb13808c ("ARM: S3C2410: move
> mach-s3c2410/* into mach-s3c24xx/"). But there is still one (pointless)
> select statement for that symbol. Drop it.
>
> Signed-off-by: Paul Bolle
> ---
> arch/arm/mach-s3c24xx/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
> index 37f513d..7361b9d 100644
> --- a/arch/arm/mach-s3c24xx/Kconfig
> +++ b/arch/arm/mach-s3c24xx/Kconfig
> @@ -320,7 +320,6 @@ config PM_H1940
>
> config MACH_N30
> bool "Acer N30 family"
> - select MACH_N35
> select S3C_DEV_NAND
> select S3C_DEV_USB_HOST
> help
> --
> 1.7.11.7
Yes, right. Applied, thanks.
BTW, so the machine type can be removed at arch/arm/tools/mach-types as well.
- Kukjin
--
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 v6 5/5] ARM: dts: Add FIMD DT binding Documentation
Sylwester Nawrocki wrote:
>
> On 03/06/2013 10:13 PM, Sylwester Nawrocki wrote:
> > @@ -305,9 +305,9 @@ struct platform_device s5p_device_jpeg = {
> > #ifdef CONFIG_S5P_DEV_FIMD0
> > static struct resource s5p_fimd0_resource[] = {
> > [0] = DEFINE_RES_MEM(S5P_PA_FIMD0, SZ_32K),
> > - [1] = DEFINE_RES_IRQ(IRQ_FIMD0_VSYNC),
> > - [2] = DEFINE_RES_IRQ(IRQ_FIMD0_FIFO),
> > - [3] = DEFINE_RES_IRQ(IRQ_FIMD0_SYSTEM),
> > + [1] = DEFINE_RES_IRQ_NAMED(IRQ_FIMD0_VSYNC, "vsync"),
> > + [2] = DEFINE_RES_IRQ(IRQ_FIMD0_FIFO, "fifo"),
> > + [3] = DEFINE_RES_IRQ(IRQ_FIMD0_SYSTEM, "system"),
> > };
>
> Oops, something missing here. Of course should be:
>
> @@ -160,9 +160,9 @@ struct platform_device samsung_asoc_idma = {
> #ifdef CONFIG_S3C_DEV_FB
> static struct resource s3c_fb_resource[] = {
> [0] = DEFINE_RES_MEM(S3C_PA_FB, SZ_16K),
> - [1] = DEFINE_RES_IRQ(IRQ_LCD_VSYNC),
> - [2] = DEFINE_RES_IRQ(IRQ_LCD_FIFO),
> - [3] = DEFINE_RES_IRQ(IRQ_LCD_SYSTEM),
> + [1] = DEFINE_RES_IRQ_NAMED(IRQ_LCD_VSYNC, "vsync"),
> + [2] = DEFINE_RES_IRQ_NAMED(IRQ_LCD_FIFO, "fifo"),
> + [3] = DEFINE_RES_IRQ_NAMED(IRQ_LCD_SYSTEM, "system"),
^^^
BTW, can you use 'tab' instead of white space at mark '^'
- Kukjin
--
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 00/23] RFC: exynos multiplatform support
On Wednesday 06 of March 2013 13:34:26 Thierry Reding wrote: > On Wed, Mar 06, 2013 at 10:50:42AM +, Arnd Bergmann wrote: > > On Tuesday 05 March 2013, Tomasz Figa wrote: > > > On Tuesday 05 of March 2013 19:19:02 Arnd Bergmann wrote: > > > > If none of these are needed for DT-based systems, we should > > > > probably > > > > build that code conditionally based on the CONFIG_EXYNOS_ATAGS > > > > symbol > > > > I introduced. > > > > > > Yes, none of them are needed for DT-based systems. > > > > Ah, good. I'll try to make more code conditional then. > > > > > > How are you planning to solve this? Do you want to have a combined > > > > driver that registers both a clocksource and a pwm? > > > > > > Let's start with a quick introduction to the s3c-pwm hardware. Each > > > channel has its own timer value, compare and reload value registers, > > > so > > > they don't need any extra locking. However there are additional > > > shared > > > configuration registers, containing things such as start and reload > > > bits for all channels, prescaler and main divisor values, etc. > > > Those registers needs synchronization. > > > > > > Now there are several possible approaches: > > > > > > 1) A brute force one - two separate drivers, based on the fact that > > > the > > > > > >clocksource driver will be used only on uniprocessor systems, so > > >a simple _irqsave when accessing a shared register in both will > > >guarantee correct synchronization. > > > > > > 2) Two separate drivers with some synchronized shared code accessing > > > > > >registers (_start, _stop, _set_reload, _set_prescaler, > > >_set_divisor, > > >etc.; all using a shared spinlock). > > > > > > 3) Single driver registering PWM channels, clocksource and clock > > > event > > > > > >device. This does not seem like a bad idea, since the whole code > > >for > > >configuration of the PWM block would reside in one location and > > >there > > >would be no redundancy. However there is a question where such > > >driver > > >should be placed - drivers/clocksource, drivers/pwm, or maybe > > >somewhere > > >else? > > > > > > Personally I wanted to go with first option, which would require > > > least > > > amount of changes to existing code, at a cost of some code > > > duplication > > > (but some PWM code is duplicated already). > > > > I would prefer option 3. That is also easier to implement with a > > straightforward DT binding that defines a single node with the clock > > registers. The location doesn't have an obvious answer, but I would > > probably put them into drivers/clocksource if the PWM maintainer > > agrees. > > > > Option 2 would probably come down to having a trivial MFD driver > > exposing a regmap. You can probably reuse drivers/mfd/syscon.c for > > this and make the node compatible with "syscon" to designate the > > clock registers as a system-wide resource, making the other device > > nodes register-less. > I think option 2 is the standard method if one hardware block provides > several logical devices. I find it to be a pretty nice solution to this > problem. We also have precedent in the PWM subsystem. The TWL chips for > instance use it to create a platform device which is later driven by a > PWM driver. I prefer this option over 3), because current driver files could be easily reused (just cleaned up and moved into appropriate directories), which would minimize the amount of needed changes. Another reason for having two separate drivers is that on Exynos SoCs the PWM block is not used for timers at all, just for PWM outputs, so the whole part responsible for clocksource would be useless. Best regards, Tomasz -- 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 00/23] RFC: exynos multiplatform support
On Wednesday 06 of March 2013 23:14:56 Heiko Stübner wrote: > Am Dienstag, 5. März 2013, 23:48:45 schrieb Tomasz Figa: > > On Tuesday 05 of March 2013 19:19:02 Arnd Bergmann wrote: > > > On Tuesday 05 March 2013, Tomasz Figa wrote: > > > > > With this patch set, we can build mach-exynos as part > > > > > of a multiplatform kernel, with the following caveats: > > > > > > > > > > * Only DT based boards are supported > > > > > > > > As far as I'm aware, there are plans to drop non-DT Exynos > > > > support. > > > > Kgene should know more on this. > > > > > > Yes, that was my understanding as well. It might not actually be too > > > hard to get multiplatform working with the ATAGS based board files > > > (we do that on some of the other platforms), but there is probably > > > no reason to try hard. > > > > > > > > * Moving to common-clk breaks things including cpufreq > > > > > > > > > > and others. Thomas is working on a patch for this > > > > > > > > We have several patches internally for fixing things up to run > > > > correclty with common-clk. I'll see if we can post some patches. > > > > > > Ok, excellent. > > > > > > > > * We disable the gpio implementation, which also breaks > > > > > > > > > > stuff, but Thomas has a patch already > > > > > > > > The legacy GPIO code is needed only for non-DT case. DT-case uses > > > > the > > > > new pinctrl-samsung driver, which is (AFAIK) multiplatform-aware. > > > > > > Please have a closer look at the "ARM: exynos: work around missing > > > gpio > > > code on multiplatform" patch, I think there a few files I had to > > > touch > > > that actually rely on the legacy gpio code: > > > > > > * the pm-gpio.c file > > > * the s3c_i2c0_cfg_gpio function > > > * the eint irqchip > > > > > > If none of these are needed for DT-based systems, we should probably > > > build that code conditionally based on the CONFIG_EXYNOS_ATAGS > > > symbol > > > I introduced. > > > > Yes, none of them are needed for DT-based systems. > > > > > > > * sparsemem support is not available on multiplatform > > > > > > > > There was some discussion some time ago whether we really need > > > > sparsemem on Exynos. If I remember correctly, it turned out that > > > > we > > > > don't. So this is not really an issue. > > > > > > Ok, good. > > > > > > > > Arnd Bergmann (23): > > > > > ARM: exynos: introduce EXYNOS_ATAGS symbol > > > > > irqchip: exynos: remove dependency on mach/irqs.h > > > > > tty: serial/samsung: prepare for common clock API > > > > > tty: serial/samsung: make register definitions global > > > > > tty: serial/samsung: fix modular build > > > > > ARM: exynos: move debug-macro.S to include/debug/ > > > > > i2c: s3c2410: make header file local > > > > > mmc: sdhci-s3c: remove platform dependencies > > > > > usb: exynos: do not include plat/usb-phy.h > > > > > [media] exynos: remove unnecessary header inclusions > > > > > video/exynos: remove unnecessary header inclusions > > > > > thermal/exynos: remove unnecessary header inclusions > > > > > mtd: onenand/samsung: make regs-onenand.h file local > > > > > rtc: s3c: make header file local > > > > > spi: s3c64xx: move to generic dmaengine API > > > > > pwm: samsung: repair the worst MMIO abuses > > > > > > > > I'm currently working (in my free time) on a series of cleanup > > > > patches > > > > sanitizing Samsung PWM code for S3C64xx and S5PV210 DT (and > > > > multiplatform) support. > > > > > > Ah, nice. > > > > > > > On those platforms it is a bit more complex case as there are two > > > > blocks of code that access the same hardware - samsung-time (using > > > > two PWM channels for clocksource and clock events) and > > > > pwm-samsung. > > > > > > > > Hopefully, I will have some patches ready soon. > > > > > > How are you planning to solve this? Do you want to have a combined > > > driver that registers both a clocksource and a pwm? > > > > Let's start with a quick introduction to the s3c-pwm hardware. Each > > channel has its own timer value, compare and reload value registers, > > so > > they don't need any extra locking. However there are additional shared > > configuration registers, containing things such as start and reload > > bits for all channels, prescaler and main divisor values, etc. Those > > registers needs synchronization. > > > > Now there are several possible approaches: > > > > 1) A brute force one - two separate drivers, based on the fact that > > the > > > >clocksource driver will be used only on uniprocessor systems, so > >a simple _irqsave when accessing a shared register in both will > >guarantee correct synchronization. > > > > 2) Two separate drivers with some synchronized shared code accessing > > > >registers (_start, _stop, _set_reload, _set_prescaler, > >_set_divisor, > >etc.; all using a shared spinlock). > > > > 3) Single driver registering PWM channels, clocksource and clock event > > > >device. This does
[PATCH] ARM: S3C24XX: drop "select MACH_N35"
The unused Kconfig symbol MACH_N35 was removed in commit
85fd6d63bf2927b9da7ab1b0d46723bfdb13808c ("ARM: S3C2410: move
mach-s3c2410/* into mach-s3c24xx/"). But there is still one (pointless)
select statement for that symbol. Drop it.
Signed-off-by: Paul Bolle
---
arch/arm/mach-s3c24xx/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 37f513d..7361b9d 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -320,7 +320,6 @@ config PM_H1940
config MACH_N30
bool "Acer N30 family"
- select MACH_N35
select S3C_DEV_NAND
select S3C_DEV_USB_HOST
help
--
1.7.11.7
--
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 00/23] RFC: exynos multiplatform support
Am Dienstag, 5. März 2013, 23:48:45 schrieb Tomasz Figa: > On Tuesday 05 of March 2013 19:19:02 Arnd Bergmann wrote: > > On Tuesday 05 March 2013, Tomasz Figa wrote: > > > > With this patch set, we can build mach-exynos as part > > > > of a multiplatform kernel, with the following caveats: > > > > > > > > * Only DT based boards are supported > > > > > > As far as I'm aware, there are plans to drop non-DT Exynos support. > > > Kgene should know more on this. > > > > Yes, that was my understanding as well. It might not actually be too > > hard to get multiplatform working with the ATAGS based board files > > (we do that on some of the other platforms), but there is probably > > no reason to try hard. > > > > > > * Moving to common-clk breaks things including cpufreq > > > > > > > > and others. Thomas is working on a patch for this > > > > > > We have several patches internally for fixing things up to run > > > correclty with common-clk. I'll see if we can post some patches. > > > > Ok, excellent. > > > > > > * We disable the gpio implementation, which also breaks > > > > > > > > stuff, but Thomas has a patch already > > > > > > The legacy GPIO code is needed only for non-DT case. DT-case uses the > > > new pinctrl-samsung driver, which is (AFAIK) multiplatform-aware. > > > > Please have a closer look at the "ARM: exynos: work around missing gpio > > code on multiplatform" patch, I think there a few files I had to touch > > that actually rely on the legacy gpio code: > > > > * the pm-gpio.c file > > * the s3c_i2c0_cfg_gpio function > > * the eint irqchip > > > > If none of these are needed for DT-based systems, we should probably > > build that code conditionally based on the CONFIG_EXYNOS_ATAGS symbol > > I introduced. > > Yes, none of them are needed for DT-based systems. > > > > > * sparsemem support is not available on multiplatform > > > > > > There was some discussion some time ago whether we really need > > > sparsemem on Exynos. If I remember correctly, it turned out that we > > > don't. So this is not really an issue. > > > > Ok, good. > > > > > > Arnd Bergmann (23): > > > > ARM: exynos: introduce EXYNOS_ATAGS symbol > > > > irqchip: exynos: remove dependency on mach/irqs.h > > > > tty: serial/samsung: prepare for common clock API > > > > tty: serial/samsung: make register definitions global > > > > tty: serial/samsung: fix modular build > > > > ARM: exynos: move debug-macro.S to include/debug/ > > > > i2c: s3c2410: make header file local > > > > mmc: sdhci-s3c: remove platform dependencies > > > > usb: exynos: do not include plat/usb-phy.h > > > > [media] exynos: remove unnecessary header inclusions > > > > video/exynos: remove unnecessary header inclusions > > > > thermal/exynos: remove unnecessary header inclusions > > > > mtd: onenand/samsung: make regs-onenand.h file local > > > > rtc: s3c: make header file local > > > > spi: s3c64xx: move to generic dmaengine API > > > > pwm: samsung: repair the worst MMIO abuses > > > > > > I'm currently working (in my free time) on a series of cleanup patches > > > sanitizing Samsung PWM code for S3C64xx and S5PV210 DT (and > > > multiplatform) support. > > > > Ah, nice. > > > > > On those platforms it is a bit more complex case as there are two > > > blocks of code that access the same hardware - samsung-time (using > > > two PWM channels for clocksource and clock events) and pwm-samsung. > > > > > > Hopefully, I will have some patches ready soon. > > > > How are you planning to solve this? Do you want to have a combined > > driver that registers both a clocksource and a pwm? > > Let's start with a quick introduction to the s3c-pwm hardware. Each > channel has its own timer value, compare and reload value registers, so > they don't need any extra locking. However there are additional shared > configuration registers, containing things such as start and reload bits > for all channels, prescaler and main divisor values, etc. Those registers > needs synchronization. > > Now there are several possible approaches: > > 1) A brute force one - two separate drivers, based on the fact that the >clocksource driver will be used only on uniprocessor systems, so >a simple _irqsave when accessing a shared register in both will >guarantee correct synchronization. > > 2) Two separate drivers with some synchronized shared code accessing >registers (_start, _stop, _set_reload, _set_prescaler, _set_divisor, >etc.; all using a shared spinlock). > > 3) Single driver registering PWM channels, clocksource and clock event >device. This does not seem like a bad idea, since the whole code for >configuration of the PWM block would reside in one location and there >would be no redundancy. However there is a question where such driver >should be placed - drivers/clocksource, drivers/pwm, or maybe somewhere >else? > > Personally I wanted to go with first option, which would require lea
Re: [PATCH v6 5/5] ARM: dts: Add FIMD DT binding Documentation
On 03/06/2013 10:13 PM, Sylwester Nawrocki wrote:
@@ -305,9 +305,9 @@ struct platform_device s5p_device_jpeg = {
#ifdef CONFIG_S5P_DEV_FIMD0
static struct resource s5p_fimd0_resource[] = {
[0] = DEFINE_RES_MEM(S5P_PA_FIMD0, SZ_32K),
- [1] = DEFINE_RES_IRQ(IRQ_FIMD0_VSYNC),
- [2] = DEFINE_RES_IRQ(IRQ_FIMD0_FIFO),
- [3] = DEFINE_RES_IRQ(IRQ_FIMD0_SYSTEM),
+ [1] = DEFINE_RES_IRQ_NAMED(IRQ_FIMD0_VSYNC, "vsync"),
+ [2] = DEFINE_RES_IRQ(IRQ_FIMD0_FIFO, "fifo"),
+ [3] = DEFINE_RES_IRQ(IRQ_FIMD0_SYSTEM, "system"),
};
Oops, something missing here. Of course should be:
@@ -160,9 +160,9 @@ struct platform_device samsung_asoc_idma = {
#ifdef CONFIG_S3C_DEV_FB
static struct resource s3c_fb_resource[] = {
[0] = DEFINE_RES_MEM(S3C_PA_FB, SZ_16K),
- [1] = DEFINE_RES_IRQ(IRQ_LCD_VSYNC),
- [2] = DEFINE_RES_IRQ(IRQ_LCD_FIFO),
- [3] = DEFINE_RES_IRQ(IRQ_LCD_SYSTEM),
+ [1] = DEFINE_RES_IRQ_NAMED(IRQ_LCD_VSYNC, "vsync"),
+ [2] = DEFINE_RES_IRQ_NAMED(IRQ_LCD_FIFO, "fifo"),
+ [3] = DEFINE_RES_IRQ_NAMED(IRQ_LCD_SYSTEM, "system"),
--
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 v6 5/5] ARM: dts: Add FIMD DT binding Documentation
On 03/06/2013 11:18 AM, Vikas Sajjan wrote:
Good idea, but i am just wondering is it a good idea to modify the
fimd driver ?
I think it is. But it depends what code quality you aim for.
Is there any issue in making a change as below ? ;)
Of course it's all up to you, I've just suggested what I thought was
an improvement to the current situation.
diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index 51afedd..4180247 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -160,9 +160,9 @@ struct platform_device samsung_asoc_idma = {
#ifdef CONFIG_S3C_DEV_FB
static struct resource s3c_fb_resource[] = {
[0] = DEFINE_RES_MEM(S3C_PA_FB, SZ_16K),
- [1] = DEFINE_RES_IRQ(IRQ_LCD_VSYNC),
- [2] = DEFINE_RES_IRQ(IRQ_LCD_FIFO),
- [3] = DEFINE_RES_IRQ(IRQ_LCD_SYSTEM),
+ [1] = DEFINE_RES_IRQ_NAMED(IRQ_LCD_VSYNC, "vsync"),
+ [2] = DEFINE_RES_IRQ_NAMED(IRQ_LCD_FIFO, "fifo"),
+ [3] = DEFINE_RES_IRQ_NAMED(IRQ_LCD_SYSTEM, "system"),
};
struct platform_device s3c_device_fb = {
@@ -305,9 +305,9 @@ struct platform_device s5p_device_jpeg = {
#ifdef CONFIG_S5P_DEV_FIMD0
static struct resource s5p_fimd0_resource[] = {
[0] = DEFINE_RES_MEM(S5P_PA_FIMD0, SZ_32K),
- [1] = DEFINE_RES_IRQ(IRQ_FIMD0_VSYNC),
- [2] = DEFINE_RES_IRQ(IRQ_FIMD0_FIFO),
- [3] = DEFINE_RES_IRQ(IRQ_FIMD0_SYSTEM),
+ [1] = DEFINE_RES_IRQ_NAMED(IRQ_FIMD0_VSYNC, "vsync"),
+ [2] = DEFINE_RES_IRQ(IRQ_FIMD0_FIFO, "fifo"),
+ [3] = DEFINE_RES_IRQ(IRQ_FIMD0_SYSTEM, "system"),
};
struct platform_device s5p_device_fimd0 = {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 36493ce..5efb4c7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -917,7 +917,7 @@ static int fimd_probe(struct platform_device *pdev)
if (IS_ERR(ctx->regs))
return PTR_ERR(ctx->regs);
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ res = platform_get_resource_byname(pdev, IORESOURCE_IRQ, "vsync");
if (!res) {
dev_err(dev, "irq request failed.\n");
return -ENXIO;
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 968a625..43af0108 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -1427,7 +1427,7 @@ static int s3c_fb_probe(struct platform_device *pdev)
goto err_lcd_clk;
}
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ res = platform_get_resource_byname(pdev, IORESOURCE_IRQ, "vsync");
if (!res) {
dev_err(dev, "failed to acquire irq resource\n");
ret = -ENOENT;
--
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] iio: adc: exynos5_adc: fix compilation warnings
On 6 March 2013 17:44, Lars-Peter Clausen wrote:
> On 03/06/2013 05:11 AM, Naveen Krishna Chatradhi wrote:
>> From: Naveen Krishna Ch
>>
>> Fixes the compilation warnings and potential NULL pointer
>> dereferencing pointed out by "Dan Carpenter".
>>
>
> I'd say that's a rather un-potential NULL pointer dereferencing, but if it
> makes the static checkers happy, why not. Since the same match table is used
> to
> match the device, probe won't be called unless there is a match, so
> of_match_node() will never return NULL in this case.
Right, i was thinking how it is such a potential error.
Anyway, Dan's suggestion of Kconfig change holds very good.
I will submit v2, with the appropriate changes.
>
>> Signed-off-by: Naveen Krishna Ch
>> ---
>> drivers/iio/adc/exynos_adc.c | 24 +---
>> 1 file changed, 17 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
>> index ed6fdd7..67d07aa 100644
>> --- a/drivers/iio/adc/exynos_adc.c
>> +++ b/drivers/iio/adc/exynos_adc.c
>> @@ -92,7 +92,7 @@ struct exynos_adc {
>> struct completion completion;
>>
>> u32 value;
>> - unsigned intversion;
>> + unsigned intversion;
>> };
>>
>> static const struct of_device_id exynos_adc_match[] = {
>> @@ -102,12 +102,15 @@ static const struct of_device_id exynos_adc_match[] = {
>> };
>> MODULE_DEVICE_TABLE(of, exynos_adc_match);
>>
>> -static inline unsigned int exynos_adc_get_version(struct platform_device
>> *pdev)
>> +static inline int exynos_adc_get_version(struct platform_device *pdev)
>> {
>> const struct of_device_id *match;
>>
>> match = of_match_node(exynos_adc_match, pdev->dev.of_node);
>> - return (unsigned int)match->data;
>> + if (!match)
>> + return -ENODEV;
>> +
>> + return (int)match->data;
>> }
>>
>> static int exynos_read_raw(struct iio_dev *indio_dev,
>> @@ -117,7 +120,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
>> long mask)
>> {
>> struct exynos_adc *info = iio_priv(indio_dev);
>> - unsigned long timeout;
>> + int timeout;
>> u32 con1, con2;
>>
>> if (mask != IIO_CHAN_INFO_RAW)
>> @@ -255,7 +258,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
>> struct iio_dev *indio_dev = NULL;
>> struct resource *mem;
>> int ret = -ENODEV;
>> - int irq;
>> + int irq, version;
>>
>> if (!np)
>> return ret;
>> @@ -268,6 +271,15 @@ static int exynos_adc_probe(struct platform_device
>> *pdev)
>>
>> info = iio_priv(indio_dev);
>>
>> + version = exynos_adc_get_version(pdev);
>> + if (version < 0) {
>> + dev_err(&pdev->dev, "no matching of_node, err = %d\n",
>> version);
>> + ret = version;
>> + goto err_iio;
>> + }
>> +
>> + info->version = version;
>> +
>> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>
>> info->regs = devm_request_and_ioremap(&pdev->dev, mem);
>> @@ -311,8 +323,6 @@ static int exynos_adc_probe(struct platform_device *pdev)
>> goto err_irq;
>> }
>>
>> - info->version = exynos_adc_get_version(pdev);
>> -
>> platform_set_drvdata(pdev, indio_dev);
>>
>> indio_dev->name = dev_name(&pdev->dev);
>
--
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/2] ARM: EXYNOS: Add PCIe driver support
Dear Thomas Abraham, On Mon, 4 Mar 2013 16:01:59 +0530, Thomas Abraham wrote: > On 4 March 2013 15:52, Jingoo Han wrote: > > Exynos5440 has two PCIe controllers which can be used as Root Complex. > > This driver supports the PCIe controllers as Root Complex mode. > > > > Signed-off-by: Surendranath Gurivireddy Balla > > Signed-off-by: Siva Reddy Kallam > > Signed-off-by: Jingoo Han > > --- > > .../devicetree/bindings/pci/exynos-pcie.txt| 58 ++ > > arch/arm/Kconfig |2 + > > arch/arm/mach-exynos/Kconfig |8 + > > arch/arm/mach-exynos/Makefile |2 + > > arch/arm/mach-exynos/include/mach/pcie.h | 146 +++ > > arch/arm/mach-exynos/pcie.c| 1009 > > > > Is there any reason to place this code in arch/arm/...? As you know, > there is a constant effort to relocate as much code as possible from > arch/arm/mach-exynos. So there must be a strong justification for > keeping this code in arch/arm/mach-exynos. Indeed. Thierry Reding (doing the Tegra PCIe driver) and myself (doing the Marvell PCIe driver) are putting our drivers in drivers/pci/host/, in agreement with the PCI maintainers. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- 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 00/23] RFC: exynos multiplatform support
On Wed, Mar 06, 2013 at 10:50:42AM +, Arnd Bergmann wrote: > On Tuesday 05 March 2013, Tomasz Figa wrote: > > On Tuesday 05 of March 2013 19:19:02 Arnd Bergmann wrote: > > > > If none of these are needed for DT-based systems, we should probably > > > build that code conditionally based on the CONFIG_EXYNOS_ATAGS symbol > > > I introduced. > > > > Yes, none of them are needed for DT-based systems. > > Ah, good. I'll try to make more code conditional then. > > > > How are you planning to solve this? Do you want to have a combined > > > driver that registers both a clocksource and a pwm? > > > > Let's start with a quick introduction to the s3c-pwm hardware. Each > > channel has its own timer value, compare and reload value registers, so > > they don't need any extra locking. However there are additional shared > > configuration registers, containing things such as start and reload bits > > for all channels, prescaler and main divisor values, etc. Those registers > > needs synchronization. > > > > Now there are several possible approaches: > > > > 1) A brute force one - two separate drivers, based on the fact that the > >clocksource driver will be used only on uniprocessor systems, so > >a simple _irqsave when accessing a shared register in both will > >guarantee correct synchronization. > > > > 2) Two separate drivers with some synchronized shared code accessing > >registers (_start, _stop, _set_reload, _set_prescaler, _set_divisor, > >etc.; all using a shared spinlock). > > > > 3) Single driver registering PWM channels, clocksource and clock event > >device. This does not seem like a bad idea, since the whole code for > >configuration of the PWM block would reside in one location and there > >would be no redundancy. However there is a question where such driver > >should be placed - drivers/clocksource, drivers/pwm, or maybe somewhere > >else? > > > > Personally I wanted to go with first option, which would require least > > amount of changes to existing code, at a cost of some code duplication > > (but some PWM code is duplicated already). > > I would prefer option 3. That is also easier to implement with a > straightforward > DT binding that defines a single node with the clock registers. The location > doesn't have an obvious answer, but I would probably put them into > drivers/clocksource if the PWM maintainer agrees. > > Option 2 would probably come down to having a trivial MFD driver exposing > a regmap. You can probably reuse drivers/mfd/syscon.c for this and make > the node compatible with "syscon" to designate the clock registers as > a system-wide resource, making the other device nodes register-less. I think option 2 is the standard method if one hardware block provides several logical devices. I find it to be a pretty nice solution to this problem. We also have precedent in the PWM subsystem. The TWL chips for instance use it to create a platform device which is later driven by a PWM driver. Thierry pgpbk06GdmLK5.pgp Description: PGP signature
[PATCH 2/2] ARM: dts: add pin state information in client nodes for Exynos5 platforms
Add default pin state information for all client nodes that require
pin configuration support using pinctrl interface.
Signed-off-by: Thomas Abraham
---
arch/arm/boot/dts/cros5250-common.dtsi| 51 +--
arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 783 +
arch/arm/boot/dts/exynos5250-smdk5250.dts | 33 +-
arch/arm/boot/dts/exynos5250-snow.dts | 22 +-
arch/arm/boot/dts/exynos5250.dtsi | 310 +++-
5 files changed, 889 insertions(+), 310 deletions(-)
create mode 100755 arch/arm/boot/dts/exynos5250-pinctrl.dtsi
diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
b/arch/arm/boot/dts/cros5250-common.dtsi
index 46c0980..e782706 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -19,31 +19,30 @@
chosen {
};
+ pinctrl@1140 {
+ /*
+* Disabled pullups since external part has its own pullups and
+* double-pulling gets us out of spec in some cases.
+*/
+ i2c2_bus: i2c2-bus {
+ samsung,pin-pud = <0>;
+ };
+ };
+
i2c@12C6 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <378000>;
- gpios = <&gpb3 0 2 3 0>,
- <&gpb3 1 2 3 0>;
};
i2c@12C7 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <378000>;
- gpios = <&gpb3 2 2 3 0>,
- <&gpb3 3 2 3 0>;
};
i2c@12C8 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <66000>;
- /*
-* Disabled pullups since external part has its own pullups and
-* double-pulling gets us out of spec in some cases.
-*/
- gpios = <&gpa0 6 3 0 0>,
- <&gpa0 7 3 0 0>;
-
hdmiddc@50 {
compatible = "samsung,exynos5-hdmiddc";
reg = <0x50>;
@@ -53,8 +52,6 @@
i2c@12C9 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <66000>;
- gpios = <&gpa1 2 3 3 0>,
- <&gpa1 3 3 3 0>;
};
i2c@12CA {
@@ -64,8 +61,6 @@
i2c@12CB {
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <66000>;
- gpios = <&gpa2 2 3 3 0>,
- <&gpa2 3 3 3 0>;
};
i2c@12CC {
@@ -75,8 +70,6 @@
i2c@12CD {
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <66000>;
- gpios = <&gpb2 2 3 3 0>,
- <&gpb2 3 3 3 0>;
};
i2c@12CE {
@@ -98,15 +91,12 @@
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <2 3>;
samsung,dw-mshc-ddr-timing = <1 2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_cd &sd0_bus4 &sd0_bus8>;
slot@0 {
reg = <0>;
bus-width = <8>;
- gpios = <&gpc0 0 2 0 3>, <&gpc0 1 2 0 3>,
- <&gpc1 0 2 3 3>, <&gpc1 1 2 3 3>,
- <&gpc1 2 2 3 3>, <&gpc1 3 2 3 3>,
- <&gpc0 3 2 3 3>, <&gpc0 4 2 3 3>,
- <&gpc0 5 2 3 3>, <&gpc0 6 2 3 3>;
};
};
@@ -122,15 +112,13 @@
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <2 3>;
samsung,dw-mshc-ddr-timing = <1 2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
slot@0 {
reg = <0>;
bus-width = <4>;
- samsung,cd-pinmux-gpio = <&gpc3 2 2 3 3>;
- wp-gpios = <&gpc2 1 0 0 3>;
- gpios = <&gpc3 0 2 0 3>, <&gpc3 1 2 0 3>,
- <&gpc3 3 2 3 3>, <&gpc3 4 2 3 3>,
- <&gpc3 5 2 3 3>, <&gpc3 6 2 3 3>;
+ wp-gpios = <&gpc2 1 0>;
};
};
@@ -143,11 +131,11 @@
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <2 3>;
samsung,dw-mshc-ddr-timing = <1 2>;
+ /* See board-specific dts files for pin setup */
slot@0 {
reg = <0>;
bus-width = <4>;
- /* See board-specific dts files for GPIOs */
};
};
@@ -156,9 +144,6 @@
};
spi_1: spi@12d3 {
- gpios = <&gpa2 4 2 3 0>,
-
[PATCH 1/2] ARM: dts: add pin state information in client nodes for Exynos4 platforms
Add default pin state information for all client nodes that require
pin configuration support using pinctrl interface.
Signed-off-by: Thomas Abraham
---
arch/arm/boot/dts/exynos4.dtsi| 10 +
arch/arm/boot/dts/exynos4210-smdkv310.dts | 53 +
2 files changed, 34 insertions(+), 29 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index e1347fc..d160892 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -165,6 +165,8 @@
compatible = "samsung,s3c2440-i2c";
reg = <0x1386 0x100>;
interrupts = <0 58 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_bus>;
status = "disabled";
};
@@ -174,6 +176,8 @@
compatible = "samsung,s3c2440-i2c";
reg = <0x1387 0x100>;
interrupts = <0 59 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_bus>;
status = "disabled";
};
@@ -239,6 +243,8 @@
rx-dma-channel = <&pdma0 6>; /* preliminary */
#address-cells = <1>;
#size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_bus>;
status = "disabled";
};
@@ -250,6 +256,8 @@
rx-dma-channel = <&pdma1 6>; /* preliminary */
#address-cells = <1>;
#size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi1_bus>;
status = "disabled";
};
@@ -261,6 +269,8 @@
rx-dma-channel = <&pdma0 8>; /* preliminary */
#address-cells = <1>;
#size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi2_bus>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/exynos4210-smdkv310.dts
b/arch/arm/boot/dts/exynos4210-smdkv310.dts
index f634907..55442a5 100644
--- a/arch/arm/boot/dts/exynos4210-smdkv310.dts
+++ b/arch/arm/boot/dts/exynos4210-smdkv310.dts
@@ -30,16 +30,9 @@
};
sdhci@1253 {
- samsung,sdhci-bus-width = <4>;
- linux,mmc_cap_4_bit_data;
- samsung,sdhci-cd-internal;
- gpio-cd = <&gpk2 2 2 3 3>;
- gpios = <&gpk2 0 2 0 3>,
- <&gpk2 1 2 0 3>,
- <&gpk2 3 2 3 3>,
- <&gpk2 4 2 3 3>,
- <&gpk2 5 2 3 3>,
- <&gpk2 6 2 3 3>;
+ bus-width = <4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
status = "okay";
};
@@ -59,25 +52,32 @@
status = "okay";
};
+ pinctrl@1100 {
+ keypad_rows: keypad-rows {
+ samsung,pins = "gpx2-0", "gpx2-1";
+ samsung,pin-function = <3>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
+ keypad_cols: keypad-cols {
+ samsung,pins = "gpx1-0", "gpx1-1", "gpx1-2", "gpx1-3",
+ "gpx1-4", "gpx1-5", "gpx1-6", "gpx1-7";
+ samsung,pin-function = <3>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+ };
+
keypad@100A {
samsung,keypad-num-rows = <2>;
samsung,keypad-num-columns = <8>;
linux,keypad-no-autorepeat;
linux,keypad-wakeup;
+ pinctrl-names = "default";
+ pinctrl-0 = <&keypad_rows &keypad_cols>;
status = "okay";
- row-gpios = <&gpx2 0 3 3 0>,
- <&gpx2 1 3 3 0>;
-
- col-gpios = <&gpx1 0 3 0 0>,
- <&gpx1 1 3 0 0>,
- <&gpx1 2 3 0 0>,
- <&gpx1 3 3 0 0>,
- <&gpx1 4 3 0 0>,
- <&gpx1 5 3 0 0>,
- <&gpx1 6 3 0 0>,
- <&gpx1 7 3 0 0>;
-
key_1 {
keypad,row = <0>;
keypad,column = <3>;
@@ -143,9 +143,7 @@
#address-cells = <1>;
#size-cells = <0>;
samsung,i2c-sda-delay = <100>;
- samsung,i2c-max-bus-freq = <2>;
- gpios = <&gpd1 0 2 3 0>,
- <&gpd1 1 2 3 0>;
+ samsung,i2c-max-bus-freq = <10>;
status = "okay";
eeprom@50 {
@@ -160,9 +158,6 @@
};
spi_2: spi@1394 {
- gpios = <&gpc1 1 5 3 0>
[PATCH 0/2] ARM: dts: Add default pin states for client nodes on Exynos4/5 platforms
This patch series populates the default pin states in client nodes of Exynos4 and Exynos5 platforms. Exynos4/5 platforms are migrating to use pinctrl framework and having the default pin states listed in the client nodes allows the device core to setup the default pin configuration for all the controllers. This means the old-styled Samsung specific gpio bindings, which have been used till now for setting up the pin configurations, will not be used anymore. The corresponding changes required in device drivers have been posted seperatly. Thomas Abraham (2): ARM: dts: add pin state information in client nodes for Exynos4 platforms ARM: dts: add pin state information in client nodes for Exynos5 platforms arch/arm/boot/dts/cros5250-common.dtsi| 51 +-- arch/arm/boot/dts/exynos4.dtsi| 10 + arch/arm/boot/dts/exynos4210-smdkv310.dts | 53 +-- arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 783 + arch/arm/boot/dts/exynos5250-smdk5250.dts | 33 +- arch/arm/boot/dts/exynos5250-snow.dts | 22 +- arch/arm/boot/dts/exynos5250.dtsi | 310 +++- 7 files changed, 923 insertions(+), 339 deletions(-) create mode 100755 arch/arm/boot/dts/exynos5250-pinctrl.dtsi -- 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 18/23] ASoC: samsung: convert to dmaengine API
On Wednesday 06 March 2013, Padma Venkat wrote:
> > + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
> > + config.direction = DMA_MEM_TO_DEV;
> > + config.dst_addr = prtd->params->dma_size;
> > + config.dst_addr_width = prtd->params->dma_addr;
>
> dma_addr and dma_size got interchanged.
Ok, fixed.
> Except the above one I tested this patch on 5250. It's working fine.
Thanks a lot for testing this!
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
[RFC 12/12] ARM: dts: Add camera node to exynos5250-smdk5250.dts
Signed-off-by: Shaik Ameer Basha
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 43 -
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 4b10744..7fbc236 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -85,9 +85,26 @@
};
i2c@12CA {
- status = "disabled";
+ samsung,i2c-sda-delay = <100>;
+ samsung,i2c-max-bus-freq = <10>;
pinctrl-0 = <&i2c4_bus>;
pinctrl-names = "default";
+
+ m5mols@1f {
+ compatible = "fujitsu,m-5mols";
+ reg = <0x1F>;
+ gpios = <&gpx3 3 0xf>, <&gpx1 2 1>;
+ clock-frequency = <2400>;
+ pinctrl-0 = <&cam_port_a_clk_active>;
+ pinctrl-names = "default";
+
+ port {
+ m5mols_ep: endpoint {
+ remote-endpoint = <&csis0_ep>;
+ };
+ };
+
+ };
};
i2c@12CB {
@@ -214,4 +231,28 @@
samsung,mfc-r = <0x4300 0x80>;
samsung,mfc-l = <0x5100 0x80>;
};
+
+ camera {
+ compatible = "samsung,exynos5-fimc", "simple-bus";
+ status = "okay";
+
+ csis_0: csis@13C2 {
+ status = "okay";
+ clock-frequency = <16600>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Camera C (3) MIPI CSI-2 (CSIS0) */
+ port@3 {
+ reg = <3>;
+ csis0_ep: endpoint {
+ remote-endpoint = <&m5mols_ep>;
+ data-lanes = <1 2 3 4>;
+ samsung,csis-hs-settle = <12>;
+ samsung,csis-wclk;
+ };
+ };
+ };
+
+ };
};
--
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
[RFC 11/12] media: m5mols: Adding dt support to m5mols driver
This patch adds the dt support to m5mols driver.
Signed-off-by: Shaik Ameer Basha
---
drivers/media/i2c/m5mols/m5mols_core.c | 54 +++-
1 file changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/m5mols/m5mols_core.c
b/drivers/media/i2c/m5mols/m5mols_core.c
index d4e7567..21c66ef 100644
--- a/drivers/media/i2c/m5mols/m5mols_core.c
+++ b/drivers/media/i2c/m5mols/m5mols_core.c
@@ -19,6 +19,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -926,13 +928,38 @@ static irqreturn_t m5mols_irq_handler(int irq, void *data)
return IRQ_HANDLED;
}
+static const struct of_device_id m5mols_match[];
+
static int m5mols_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- const struct m5mols_platform_data *pdata = client->dev.platform_data;
+ struct m5mols_platform_data *pdata;
struct m5mols_info *info;
+ const struct of_device_id *of_id;
struct v4l2_subdev *sd;
int ret;
+ struct pinctrl *pctrl;
+ int eint_gpio = 0;
+
+ if (client->dev.of_node) {
+ of_id = of_match_node(m5mols_match, client->dev.of_node);
+ if (of_id)
+ pdata = (struct m5mols_platform_data *)of_id->data;
+ client->dev.platform_data = pdata;
+ } else {
+ pdata = client->dev.platform_data;
+ }
+
+ if (!pdata)
+ return -EINVAL;
+
+ pctrl = devm_pinctrl_get_select_default(&client->dev);
+ if (client->dev.of_node) {
+ eint_gpio = of_get_named_gpio(client->dev.of_node, "gpios", 0);
+ client->irq = gpio_to_irq(eint_gpio);
+ pdata->gpio_reset = of_get_named_gpio(client->dev.of_node,
+ "gpios", 1);
+ }
if (pdata == NULL) {
dev_err(&client->dev, "No platform data\n");
@@ -1040,9 +1067,34 @@ static const struct i2c_device_id m5mols_id[] = {
};
MODULE_DEVICE_TABLE(i2c, m5mols_id);
+static int m5mols_set_power(struct device *dev, int on)
+{
+ struct m5mols_platform_data *pdata =
+ (struct m5mols_platform_data *)dev->platform_data;
+ gpio_set_value(pdata->gpio_reset, !on);
+ gpio_set_value(pdata->gpio_reset, !!on);
+ return 0;
+}
+
+static struct m5mols_platform_data m5mols_drvdata = {
+ .gpio_reset = 0,
+ .reset_polarity = 0,
+ .set_power = m5mols_set_power,
+};
+
+static const struct of_device_id m5mols_match[] = {
+ {
+ .compatible = "fujitsu,m-5mols",
+ .data = &m5mols_drvdata,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, m5mols_match);
+
static struct i2c_driver m5mols_i2c_driver = {
.driver = {
.name = MODULE_NAME,
+ .of_match_table = m5mols_match,
},
.probe = m5mols_probe,
.remove = m5mols_remove,
--
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
[RFC 10/12] ARM: dts: Adding media device nodes to Exynos5 SoCs
This patch adds the media device driver specific dt bindings
to the Exynos5 specific SoCs.
Signed-off-by: Shaik Ameer Basha
---
arch/arm/boot/dts/exynos5250.dtsi | 64 +
1 file changed, 36 insertions(+), 28 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index e09cda0..564c05f 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -370,37 +370,45 @@
interrupts = <0 94 0>;
};
- csis_0: csis@13C2 {
- compatible = "samsung,exynos5250-csis";
- reg = <0x13C2 0x4000>;
- interrupts = <0 79 0>;
- bus-width = <4>;
- status = "disabled";
- };
+ camera {
+ compatible = "samsung,exynos5-fimc", "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
- csis_1: csis@13C3 {
- compatible = "samsung,exynos5250-csis";
- reg = <0x13C3 0x4000>;
- interrupts = <0 80 0>;
- bus-width = <4>;
- status = "disabled";
- };
+ fimc_lite_0: fimc-lite@13C0 {
+ compatible = "samsung,exynos5250-fimc-lite";
+ reg = <0x13C0 0x1000>;
+ interrupts = <0 125 0>;
+ };
- fimc_lite_0: fimc-lite@13C0 {
- compatible = "samsung,exynos5250-fimc-lite";
- reg = <0x13C0 0x1000>;
- interrupts = <0 125 0>;
- };
+ fimc_lite_1: fimc-lite@13C1 {
+ compatible = "samsung,exynos5250-fimc-lite";
+ reg = <0x13C1 0x1000>;
+ interrupts = <0 126 0>;
+ };
- fimc_lite_1: fimc-lite@13C1 {
- compatible = "samsung,exynos5250-fimc-lite";
- reg = <0x13C1 0x1000>;
- interrupts = <0 126 0>;
- };
+ fimc_lite_2: fimc-lite@13C9 {
+ compatible = "samsung,exynos5250-fimc-lite";
+ reg = <0x13C9 0x1000>;
+ interrupts = <0 110 0>;
+ };
- fimc_lite_2: fimc-lite@13C9 {
- compatible = "samsung,exynos5250-fimc-lite";
- reg = <0x13C9 0x1000>;
- interrupts = <0 110 0>;
+ csis_0: csis@13C2 {
+ compatible = "samsung,exynos5250-csis";
+ reg = <0x13C2 0x4000>;
+ interrupts = <0 79 0>;
+ bus-width = <4>;
+ clock-names = "csis", "sclk_csis", "mux", "parent";
+ status = "disabled";
+ };
+
+ csis_1: csis@13C3 {
+ compatible = "samsung,exynos5250-csis";
+ reg = <0x13C3 0x4000>;
+ interrupts = <0 80 0>;
+ bus-width = <2>;
+ status = "disabled";
+ };
};
};
--
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
[RFC 09/12] ARM: dts: Adding pinctrl support to Exynos5250 i2c nodes
This patch adds the default pinctrl functionality to the
i2c device nodes on exynos5250-smdk5250.dts file
Signed-off-by: Shaik Ameer Basha
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 942d576..4b10744 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -30,8 +30,8 @@
i2c@12C6 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <2>;
- gpios = <&gpb3 0 2 3 0>,
- <&gpb3 1 2 3 0>;
+ pinctrl-0 = <&i2c0_bus>;
+ pinctrl-names = "default";
eeprom@50 {
compatible = "samsung,s524ad0xd1";
@@ -42,8 +42,8 @@
i2c@12C7 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <2>;
- gpios = <&gpb3 2 2 3 0>,
- <&gpb3 3 2 3 0>;
+ pinctrl-0 = <&i2c1_bus>;
+ pinctrl-names = "default";
eeprom@51 {
compatible = "samsung,s524ad0xd1";
@@ -69,8 +69,8 @@
i2c@12C8 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <66000>;
- gpios = <&gpa0 6 3 3 0>,
- <&gpa0 7 3 3 0>;
+ pinctrl-0 = <&i2c2_bus>;
+ pinctrl-names = "default";
hdmiddc@50 {
compatible = "samsung,exynos5-hdmiddc";
@@ -80,22 +80,32 @@
i2c@12C9 {
status = "disabled";
+ pinctrl-0 = <&i2c3_bus>;
+ pinctrl-names = "default";
};
i2c@12CA {
status = "disabled";
+ pinctrl-0 = <&i2c4_bus>;
+ pinctrl-names = "default";
};
i2c@12CB {
status = "disabled";
+ pinctrl-0 = <&i2c5_bus>;
+ pinctrl-names = "default";
};
i2c@12CC {
status = "disabled";
+ pinctrl-0 = <&i2c6_bus>;
+ pinctrl-names = "default";
};
i2c@12CD {
status = "disabled";
+ pinctrl-0 = <&i2c7_bus>;
+ pinctrl-names = "default";
};
i2c@12CE {
--
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
[RFC 08/12] ARM: dts: add camera specific pinctrl nodes for Exynos5250 SoC
Add device nodes for pinctrl group-1 for Exynos5250 SoC.
This only adds cam1 specific pinctrl nodes to the file.
Signed-off-by: Shaik Ameer Basha
---
arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 41 +
arch/arm/boot/dts/exynos5250.dtsi |7 +
2 files changed, 48 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
index 24180fc..3caaa21 100644
--- a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
@@ -555,6 +555,47 @@
};
};
+ pinctrl@1340 {
+ gph0: gph0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gph1: gph1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ cam_port_a_io: cam-port-a-io {
+ samsung,pins = "gph0-0", "gph0-1", "gph0-2", "gph0-3",
+ "gph1-0", "gph1-1", "gph1-2", "gph1-3",
+ "gph1-4", "gph1-5", "gph1-6", "gph1-7";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <3>;
+ };
+
+ cam_port_a_clk_active: cam-port-a-clk-active {
+ samsung,pins = "gph0-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <3>;
+ };
+
+ cam_port_a_clk_idle: cam-port-a-clk-idle {
+ samsung,pins = "gph0-3";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+ };
+
pinctrl_3: pinctrl@0368 {
gpz: gpz {
gpio-controller;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 4754865..e09cda0 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -37,6 +37,7 @@
mshc2 = &dwmmc_2;
mshc3 = &dwmmc_3;
pinctrl0 = &pinctrl_0;
+ pinctrl1 = &pinctrl_1;
pinctrl3 = &pinctrl_3;
i2c0 = &i2c_0;
i2c1 = &i2c_1;
@@ -95,6 +96,12 @@
};
};
+ pinctrl_1: pinctrl@1340 {
+ compatible = "samsung,pinctrl-exynos5250";
+ reg = <0x1340 0x1000>;
+ interrupts = <0 47 0>;
+ };
+
pinctrl_3: pinctrl@0368 {
compatible = "samsung,pinctrl-exynos5250";
reg = <0x0368000 0x1000>;
--
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
[RFC 07/12] media: exynos5-is: Adding media device driver for exynos5
This patch adds support for media device for EXYNOS5 SoCs.
The current media device supports the following ips to connect
through the media controller framework.
* MIPI-CSIS
Support interconnection(subdev interface) between devices
* FIMC-LITE
Support capture interface from device(Sensor, MIPI-CSIS) to memory
Support interconnection(subdev interface) between devices
G-Scaler will be added later to the current media device.
* Gscaler: general scaler
Support memory to memory interface
Support output interface from memory to display device(LCD, TV)
Support capture interface from device(FIMC-LITE, FIMD) to memory
--> media 0
Camera Capture path consists of MIPI-CSIS, FIMC-LITE and G-Scaler
++ +---+ +-+
| Sensor | --> | FIMC-LITE | --> | G-Scaler-capture |
++ +---+ +-+
++ +---+ +---+ +-+
| Sensor | --> | MIPI-CSIS | --> | FIMC-LITE | --> | G-Scaler-capture |
++ +---+ +---+ +-+
Signed-off-by: Shaik Ameer Basha
---
drivers/media/platform/Kconfig |1 +
drivers/media/platform/Makefile |1 +
drivers/media/platform/exynos5-is/Kconfig|7 +
drivers/media/platform/exynos5-is/Makefile |4 +
drivers/media/platform/exynos5-is/exynos5-mdev.c | 1309 ++
drivers/media/platform/exynos5-is/exynos5-mdev.h | 107 ++
6 files changed, 1429 insertions(+)
create mode 100644 drivers/media/platform/exynos5-is/Kconfig
create mode 100644 drivers/media/platform/exynos5-is/Makefile
create mode 100644 drivers/media/platform/exynos5-is/exynos5-mdev.c
create mode 100644 drivers/media/platform/exynos5-is/exynos5-mdev.h
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 2433e2b..f74bd92 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -123,6 +123,7 @@ config VIDEO_S3C_CAMIF
source "drivers/media/platform/soc_camera/Kconfig"
source "drivers/media/platform/s5p-fimc/Kconfig"
+source "drivers/media/platform/exynos5-is/Kconfig"
source "drivers/media/platform/s5p-tv/Kconfig"
endif # V4L_PLATFORM_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 42089ba..43da7ab 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV)+= s5p-tv/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)+= s5p-g2d/
obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/
+obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS5_MDEV) += exynos5-is/
obj-$(CONFIG_BLACKFIN) += blackfin/
diff --git a/drivers/media/platform/exynos5-is/Kconfig
b/drivers/media/platform/exynos5-is/Kconfig
new file mode 100644
index 000..7aacf3b
--- /dev/null
+++ b/drivers/media/platform/exynos5-is/Kconfig
@@ -0,0 +1,7 @@
+config VIDEO_SAMSUNG_EXYNOS5_MDEV
+ bool "Samsung Exynos5 Media Device driver"
+ depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_EXYNOS5
+ help
+ This is a v4l2 based media controller driver for
+ Exynos5 SoC.
+
diff --git a/drivers/media/platform/exynos5-is/Makefile
b/drivers/media/platform/exynos5-is/Makefile
new file mode 100644
index 000..472d8e1
--- /dev/null
+++ b/drivers/media/platform/exynos5-is/Makefile
@@ -0,0 +1,4 @@
+ccflags-y += -Idrivers/media/platform/s5p-fimc
+exynos-mdevice-objs := exynos5-mdev.o
+
+obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS5_MDEV) += exynos-mdevice.o
diff --git a/drivers/media/platform/exynos5-is/exynos5-mdev.c
b/drivers/media/platform/exynos5-is/exynos5-mdev.c
new file mode 100644
index 000..1158696
--- /dev/null
+++ b/drivers/media/platform/exynos5-is/exynos5-mdev.c
@@ -0,0 +1,1309 @@
+/*
+ * S5P/EXYNOS4 SoC series camera host interface media device driver
+ *
+ * Copyright (C) 2011 - 2012 Samsung Electronics Co., Ltd.
+ * Sylwester Nawrocki
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published
+ * by the Free Software Foundation, either version 2 of the License,
+ * or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "exynos5-mdev.h"
+
+#define dbg(fmt, args...) \
+ pr_debug("%s:%d: " fmt "\n", __func__, __LINE__, ##args)
+
+static struct fimc_md *g_exynos_mdev;
+
+static int fimc_md_set_camclk(struct v4l2_subdev *sd, bool on);
+static int __fimc_md_set_camclk(struct fimc_md *fmd,
+ struct fimc_sensor_info *s_info,
+ bool on);
+/**
+ * fimc_pipeline_prepare - update pipeline information with subdevice pointers
+ * @fimc: fimc device terminating the
[RFC 06/12] ARM: EXYNOS: Add devicetree node for FIMC-LITE driver for exynos5
This patch adds necessary source definitions needed for FIMC-LITE
driver and adds devicetree node for exynos5250.
Signed-off-by: Shaik Ameer Basha
---
arch/arm/boot/dts/exynos5250.dtsi | 21 +
arch/arm/mach-exynos/clock-exynos5.c|4
arch/arm/mach-exynos/include/mach/map.h |4
arch/arm/mach-exynos/mach-exynos5-dt.c |6 ++
4 files changed, 35 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 4fff98b..4754865 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -49,6 +49,9 @@
i2c8 = &i2c_8;
csis0 = &csis_0;
csis1 = &csis_1;
+ fimc-lite0 = &fimc_lite_0;
+ fimc-lite1 = &fimc_lite_1;
+ fimc-lite2 = &fimc_lite_2;
};
gic:interrupt-controller@10481000 {
@@ -375,4 +378,22 @@
bus-width = <4>;
status = "disabled";
};
+
+ fimc_lite_0: fimc-lite@13C0 {
+ compatible = "samsung,exynos5250-fimc-lite";
+ reg = <0x13C0 0x1000>;
+ interrupts = <0 125 0>;
+ };
+
+ fimc_lite_1: fimc-lite@13C1 {
+ compatible = "samsung,exynos5250-fimc-lite";
+ reg = <0x13C1 0x1000>;
+ interrupts = <0 126 0>;
+ };
+
+ fimc_lite_2: fimc-lite@13C9 {
+ compatible = "samsung,exynos5250-fimc-lite";
+ reg = <0x13C9 0x1000>;
+ interrupts = <0 110 0>;
+ };
};
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index 34a22ff..4536515 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -859,6 +859,10 @@ static struct clk exynos5_init_clocks_off[] = {
.enable = exynos5_clk_ip_gscl_ctrl,
.ctrlbit= (1 << 3),
}, {
+ .name = "flite",
+ .enable = exynos5_clk_ip_gscl_ctrl,
+ .ctrlbit= (1 << 4),
+ }, {
.name = "csis",
.devname= "s5p-mipi-csis.0",
.enable = exynos5_clk_ip_gscl_ctrl,
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index c834321..5bfc744 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -125,6 +125,10 @@
#define EXYNOS4_PA_SYSMMU_MFC_L0x1362
#define EXYNOS4_PA_SYSMMU_MFC_R0x1363
+#define EXYNOS5_PA_FIMC_LITE0 0x13C0
+#define EXYNOS5_PA_FIMC_LITE1 0x13C1
+#define EXYNOS5_PA_FIMC_LITE2 0x13C9
+
#define EXYNOS5_PA_GSC00x13E0
#define EXYNOS5_PA_GSC10x13E1
#define EXYNOS5_PA_GSC20x13E2
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index c420349..f6c3223 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -108,6 +108,12 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[] __initconst = {
"s5p-mipi-csis.0", NULL),
OF_DEV_AUXDATA("samsung,exynos5250-csis", EXYNOS5_PA_MIPI_CSIS1,
"s5p-mipi-csis.1", NULL),
+ OF_DEV_AUXDATA("samsung,exynos5250-fimc-lite", EXYNOS5_PA_FIMC_LITE0,
+ "exynos5-fimc-lite.0", NULL),
+ OF_DEV_AUXDATA("samsung,exynos5250-fimc-lite", EXYNOS5_PA_FIMC_LITE1,
+ "exynos5-fimc-lite.1", NULL),
+ OF_DEV_AUXDATA("samsung,exynos5250-fimc-lite", EXYNOS5_PA_FIMC_LITE2,
+ "exynos5-fimc-lite.2", 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
[RFC 05/12] ARM: EXYNOS: Add devicetree node for mipi-csis driver for exynos5
This patch adds necessary source definations needed for mipi-csis
driver and adds devicetree node for exynos5250.
Signed-off-by: Shaik Ameer Basha
---
arch/arm/boot/dts/exynos5250.dtsi | 18 ++
arch/arm/mach-exynos/clock-exynos5.c| 16 ++--
arch/arm/mach-exynos/include/mach/map.h |3 +++
arch/arm/mach-exynos/mach-exynos5-dt.c |4
4 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 3a2cd9a..4fff98b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -47,6 +47,8 @@
i2c6 = &i2c_6;
i2c7 = &i2c_7;
i2c8 = &i2c_8;
+ csis0 = &csis_0;
+ csis1 = &csis_1;
};
gic:interrupt-controller@10481000 {
@@ -357,4 +359,20 @@
reg = <0x1445 0x1>;
interrupts = <0 94 0>;
};
+
+ csis_0: csis@13C2 {
+ compatible = "samsung,exynos5250-csis";
+ reg = <0x13C2 0x4000>;
+ interrupts = <0 79 0>;
+ bus-width = <4>;
+ status = "disabled";
+ };
+
+ csis_1: csis@13C3 {
+ compatible = "samsung,exynos5250-csis";
+ reg = <0x13C3 0x4000>;
+ interrupts = <0 80 0>;
+ bus-width = <4>;
+ status = "disabled";
+ };
};
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index e9d7b80..34a22ff 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -859,6 +859,16 @@ static struct clk exynos5_init_clocks_off[] = {
.enable = exynos5_clk_ip_gscl_ctrl,
.ctrlbit= (1 << 3),
}, {
+ .name = "csis",
+ .devname= "s5p-mipi-csis.0",
+ .enable = exynos5_clk_ip_gscl_ctrl,
+ .ctrlbit= (1 << 5),
+ }, {
+ .name = "csis",
+ .devname= "s5p-mipi-csis.1",
+ .enable = exynos5_clk_ip_gscl_ctrl,
+ .ctrlbit= (1 << 6),
+ }, {
.name = SYSMMU_CLOCK_NAME,
.devname= SYSMMU_CLOCK_DEVNAME(mfc_l, 0),
.enable = &exynos5_clk_ip_mfc_ctrl,
@@ -1263,9 +1273,10 @@ static struct clksrc_clk exynos5_clksrcs[] = {
.reg_div = { .reg = EXYNOS5_CLKDIV_FSYS0, .shift = 20, .size =
4 },
}, {
.clk= {
- .name = "sclk_gscl_wrap",
+ .name = "sclk_csis",
.devname= "s5p-mipi-csis.0",
.enable = exynos5_clksrc_mask_gscl_ctrl,
+ .parent = &exynos5_clk_mout_mpll_user.clk,
.ctrlbit= (1 << 24),
},
.sources = &exynos5_clkset_group,
@@ -1273,9 +1284,10 @@ static struct clksrc_clk exynos5_clksrcs[] = {
.reg_div = { .reg = EXYNOS5_CLKDIV_GSCL, .shift = 24, .size = 4
},
}, {
.clk= {
- .name = "sclk_gscl_wrap",
+ .name = "sclk_csis",
.devname= "s5p-mipi-csis.1",
.enable = exynos5_clksrc_mask_gscl_ctrl,
+ .parent = &exynos5_clk_mout_mpll_user.clk,
.ctrlbit= (1 << 28),
},
.sources = &exynos5_clkset_group,
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 1df6abb..c834321 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -177,6 +177,9 @@
#define EXYNOS4_PA_MIPI_CSIS0 0x1188
#define EXYNOS4_PA_MIPI_CSIS1 0x1189
+#define EXYNOS5_PA_MIPI_CSIS0 0x13C2
+#define EXYNOS5_PA_MIPI_CSIS1 0x13C3
+
#define EXYNOS4_PA_FIMD0 0x11C0
#define EXYNOS4_PA_HSMMC(x)(0x1251 + ((x) * 0x1))
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index e99d3d8..c420349 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -104,6 +104,10 @@ static const struct of_dev_auxdata
exynos5250_auxdata_lookup[] __initconst = {
OF_DEV_AUXDATA("samsung,mfc-v6", 0x1100, "s5p-mfc-v6", NULL),
OF_DEV_AUXDATA("samsung,exynos5250-tmu", 0x1006,
"exynos-tmu", NULL),
+ OF_DEV_AUXDATA("samsung,exynos5250-csis", EXYNOS5_PA_MIPI_CSIS0,
+ "s5p-mipi-csis.0", NULL),
+ OF_DEV_AUXDATA
[RFC 04/12] s5p-csis: Adding Exynos5250 compatibility
Signed-off-by: Shaik Ameer Basha
---
drivers/media/platform/s5p-fimc/mipi-csis.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/s5p-fimc/mipi-csis.c
b/drivers/media/platform/s5p-fimc/mipi-csis.c
index df4411c..debda7c 100644
--- a/drivers/media/platform/s5p-fimc/mipi-csis.c
+++ b/drivers/media/platform/s5p-fimc/mipi-csis.c
@@ -1002,6 +1002,7 @@ static const struct dev_pm_ops s5pcsis_pm_ops = {
static const struct of_device_id s5pcsis_of_match[] __devinitconst = {
{ .compatible = "samsung,exynos3110-csis" },
{ .compatible = "samsung,exynos4210-csis" },
+ { .compatible = "samsung,exynos5250-csis" },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, s5pcsis_of_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
[RFC 03/12] media: fimc-lite: Adding support for Exynos5
This patch adds the following functionalities to existing driver
1] FIMC-LITE supports multiple DMA shadow registers from Exynos5 onwards.
This patch adds the functionality of using shadow registers by
checking the current FIMC-LITE hardware version.
2] Fixes Buffer corruption on DMA output from fimc-lite
3] Modified the driver to be used as pipeline endpoint
Signed-off-by: Shaik Ameer Basha
Signed-off-by: Arun Kumar K
---
drivers/media/platform/s5p-fimc/fimc-lite-reg.c | 16 +-
drivers/media/platform/s5p-fimc/fimc-lite-reg.h | 41 -
drivers/media/platform/s5p-fimc/fimc-lite.c | 196 +--
drivers/media/platform/s5p-fimc/fimc-lite.h |3 +-
4 files changed, 236 insertions(+), 20 deletions(-)
diff --git a/drivers/media/platform/s5p-fimc/fimc-lite-reg.c
b/drivers/media/platform/s5p-fimc/fimc-lite-reg.c
index 3c7dd65..3d63526 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite-reg.c
+++ b/drivers/media/platform/s5p-fimc/fimc-lite-reg.c
@@ -68,7 +68,8 @@ void flite_hw_set_interrupt_mask(struct fimc_lite *dev)
if (atomic_read(&dev->out_path) == FIMC_IO_DMA) {
intsrc = FLITE_REG_CIGCTRL_IRQ_OVFEN |
FLITE_REG_CIGCTRL_IRQ_LASTEN |
-FLITE_REG_CIGCTRL_IRQ_STARTEN;
+FLITE_REG_CIGCTRL_IRQ_STARTEN |
+FLITE_REG_CIGCTRL_IRQ_ENDEN;
} else {
/* An output to the FIMC-IS */
intsrc = FLITE_REG_CIGCTRL_IRQ_OVFEN |
@@ -215,6 +216,18 @@ void flite_hw_set_camera_bus(struct fimc_lite *dev,
flite_hw_set_camera_port(dev, si->mux_id);
}
+static void flite_hw_set_pack12(struct fimc_lite *dev, int on)
+{
+ u32 cfg = readl(dev->regs + FLITE_REG_CIODMAFMT);
+
+ cfg &= ~FLITE_REG_CIODMAFMT_PACK12;
+
+ if (on)
+ cfg |= FLITE_REG_CIODMAFMT_PACK12;
+
+ writel(cfg, dev->regs + FLITE_REG_CIODMAFMT);
+}
+
static void flite_hw_set_out_order(struct fimc_lite *dev, struct flite_frame
*f)
{
static const u32 pixcode[4][2] = {
@@ -267,6 +280,7 @@ void flite_hw_set_output_dma(struct fimc_lite *dev, struct
flite_frame *f,
flite_hw_set_out_order(dev, f);
flite_hw_set_dma_window(dev, f);
+ flite_hw_set_pack12(dev, 0);
}
void flite_hw_dump_regs(struct fimc_lite *dev, const char *label)
diff --git a/drivers/media/platform/s5p-fimc/fimc-lite-reg.h
b/drivers/media/platform/s5p-fimc/fimc-lite-reg.h
index 0e34584..716df6c 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite-reg.h
+++ b/drivers/media/platform/s5p-fimc/fimc-lite-reg.h
@@ -120,6 +120,10 @@
/* b0: 1 - camera B, 0 - camera A */
#define FLITE_REG_CIGENERAL_CAM_B (1 << 0)
+
+#define FLITE_REG_CIFCNTSEQ0x100
+#define FLITE_REG_CIOSAN(x)(0x200 + (4 * (x)))
+
/*
* Function declarations
*/
@@ -143,8 +147,41 @@ void flite_hw_set_dma_window(struct fimc_lite *dev, struct
flite_frame *f);
void flite_hw_set_test_pattern(struct fimc_lite *dev, bool on);
void flite_hw_dump_regs(struct fimc_lite *dev, const char *label);
-static inline void flite_hw_set_output_addr(struct fimc_lite *dev, u32 paddr)
+static inline void flite_hw_set_output_addr(struct fimc_lite *dev,
+ u32 paddr, u32 index)
+{
+ u32 config;
+
+ /* FLITE in EXYNOS4 has only one DMA register */
+ if (dev->variant->version == FLITE_VER_EXYNOS4)
+ index = 0;
+
+ config = readl(dev->regs + FLITE_REG_CIFCNTSEQ);
+ config |= 1 << index;
+ writel(config, dev->regs + FLITE_REG_CIFCNTSEQ);
+
+ if (index == 0)
+ writel(paddr, dev->regs + FLITE_REG_CIOSA);
+ else
+ writel(paddr, dev->regs + FLITE_REG_CIOSAN(index-1));
+}
+
+static inline void flite_hw_clear_output_addr(struct fimc_lite *dev, u32 index)
{
- writel(paddr, dev->regs + FLITE_REG_CIOSA);
+ u32 config;
+
+ /* FLITE in EXYNOS4 has only one DMA register */
+ if (dev->variant->version == FLITE_VER_EXYNOS4)
+ index = 0;
+
+ config = readl(dev->regs + FLITE_REG_CIFCNTSEQ);
+ config &= ~(1 << index);
+ writel(config, dev->regs + FLITE_REG_CIFCNTSEQ);
}
+
+static inline void flite_hw_clear_output_index(struct fimc_lite *dev)
+{
+ writel(0, dev->regs + FLITE_REG_CIFCNTSEQ);
+}
+
#endif /* FIMC_LITE_REG_H */
diff --git a/drivers/media/platform/s5p-fimc/fimc-lite.c
b/drivers/media/platform/s5p-fimc/fimc-lite.c
index eb64f87..1edc5ce 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite.c
+++ b/drivers/media/platform/s5p-fimc/fimc-lite.c
@@ -136,6 +136,8 @@ static int fimc_lite_hw_init(struct fimc_lite *fimc, bool
isp_output)
if (fimc->fmt == NULL)
return -EINVAL;
+ flite_hw_clear_output_index(fimc);
+
/* Get sensor configuration data from the sensor subdev */
src_
[RFC 02/12] fimc-lite: Adding Exynos5 compatibility to fimc-lite driver
This patch adds the Exynos5 soc compatibility to the fimc-lite driver.
It also adds a version checking to deal with the changes between
different fimc-lite hardware versions.
Signed-off-by: Shaik Ameer Basha
---
drivers/media/platform/s5p-fimc/fimc-lite.c | 23 +++
drivers/media/platform/s5p-fimc/fimc-lite.h |7 ++-
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-fimc/fimc-lite.c
b/drivers/media/platform/s5p-fimc/fimc-lite.c
index 122cf95..eb64f87 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite.c
+++ b/drivers/media/platform/s5p-fimc/fimc-lite.c
@@ -1653,6 +1653,16 @@ static struct flite_variant fimc_lite0_variant_exynos4 =
{
.out_width_align= 8,
.win_hor_offs_align = 2,
.out_hor_offs_align = 8,
+ .version= FLITE_VER_EXYNOS4,
+};
+
+static struct flite_variant fimc_lite0_variant_exynos5 = {
+ .max_width = 8192,
+ .max_height = 8192,
+ .out_width_align= 8,
+ .win_hor_offs_align = 2,
+ .out_hor_offs_align = 8,
+ .version= FLITE_VER_EXYNOS5,
};
/* EXYNOS4212, EXYNOS4412 */
@@ -1663,6 +1673,15 @@ static struct flite_drvdata fimc_lite_drvdata_exynos4 = {
},
};
+/* EXYNOS5250 */
+static struct flite_drvdata fimc_lite_drvdata_exynos5 = {
+ .variant = {
+ [0] = &fimc_lite0_variant_exynos5,
+ [1] = &fimc_lite0_variant_exynos5,
+ [2] = &fimc_lite0_variant_exynos5,
+ },
+};
+
static struct platform_device_id fimc_lite_driver_ids[] = {
{
.name = "exynos-fimc-lite",
@@ -1677,6 +1696,10 @@ static const struct of_device_id flite_of_match[] = {
.compatible = "samsung,exynos4212-fimc-lite",
.data = &fimc_lite_drvdata_exynos4,
},
+ {
+ .compatible = "samsung,exynos5250-fimc-lite",
+ .data = &fimc_lite_drvdata_exynos5,
+ },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, flite_of_match);
diff --git a/drivers/media/platform/s5p-fimc/fimc-lite.h
b/drivers/media/platform/s5p-fimc/fimc-lite.h
index 66d6eeb..ef43fe0 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite.h
+++ b/drivers/media/platform/s5p-fimc/fimc-lite.h
@@ -28,7 +28,7 @@
#define FIMC_LITE_DRV_NAME "exynos-fimc-lite"
#define FLITE_CLK_NAME "flite"
-#define FIMC_LITE_MAX_DEVS 2
+#define FIMC_LITE_MAX_DEVS 3
#define FLITE_REQ_BUFS_MIN 2
/* Bit index definitions for struct fimc_lite::state */
@@ -49,12 +49,17 @@ enum {
#define FLITE_SD_PAD_SOURCE_ISP2
#define FLITE_SD_PADS_NUM 3
+#define FLITE_VER_EXYNOS4 0
+#define FLITE_VER_EXYNOS5 1
+
+
struct flite_variant {
unsigned short max_width;
unsigned short max_height;
unsigned short out_width_align;
unsigned short win_hor_offs_align;
unsigned short out_hor_offs_align;
+ unsigned short version;
};
struct flite_drvdata {
--
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
[RFC 01/12] media: s5p-fimc: modify existing mdev to use common pipeline
This patch modifies the current fimc_pipeline to exynos_pipeline,
which can be used across multiple media device drivers.
Signed-off-by: Shaik Ameer Basha
---
drivers/media/platform/s5p-fimc/fimc-capture.c | 96 +++-
drivers/media/platform/s5p-fimc/fimc-core.h|4 +-
drivers/media/platform/s5p-fimc/fimc-lite.c| 73 --
drivers/media/platform/s5p-fimc/fimc-lite.h|4 +-
drivers/media/platform/s5p-fimc/fimc-mdevice.c | 186 ++--
drivers/media/platform/s5p-fimc/fimc-mdevice.h | 41 +++---
include/media/s5p_fimc.h | 66 ++---
7 files changed, 326 insertions(+), 144 deletions(-)
diff --git a/drivers/media/platform/s5p-fimc/fimc-capture.c
b/drivers/media/platform/s5p-fimc/fimc-capture.c
index 4cbaf46..106466e 100644
--- a/drivers/media/platform/s5p-fimc/fimc-capture.c
+++ b/drivers/media/platform/s5p-fimc/fimc-capture.c
@@ -27,24 +27,26 @@
#include
#include
-#include "fimc-mdevice.h"
#include "fimc-core.h"
#include "fimc-reg.h"
static int fimc_capture_hw_init(struct fimc_dev *fimc)
{
struct fimc_ctx *ctx = fimc->vid_cap.ctx;
- struct fimc_pipeline *p = &fimc->pipeline;
+ struct exynos_pipeline *p = &fimc->pipeline;
struct fimc_sensor_info *sensor;
unsigned long flags;
+ struct v4l2_subdev *sd;
int ret = 0;
- if (p->subdevs[IDX_SENSOR] == NULL || ctx == NULL)
+ sd = exynos_pipeline_get_subdev(fimc->pipeline_ops,
+ get_subdev_sensor, p);
+ if (sd == NULL || ctx == NULL)
return -ENXIO;
if (ctx->s_frame.fmt == NULL)
return -EINVAL;
- sensor = v4l2_get_subdev_hostdata(p->subdevs[IDX_SENSOR]);
+ sensor = v4l2_get_subdev_hostdata(sd);
spin_lock_irqsave(&fimc->slock, flags);
fimc_prepare_dma_offset(ctx, &ctx->d_frame);
@@ -118,7 +120,7 @@ static int fimc_capture_state_cleanup(struct fimc_dev
*fimc, bool suspend)
spin_unlock_irqrestore(&fimc->slock, flags);
if (streaming)
- return fimc_pipeline_call(fimc, set_stream,
+ return exynos_pipeline_call(fimc, set_stream,
&fimc->pipeline, 0);
else
return 0;
@@ -177,13 +179,16 @@ static int fimc_capture_config_update(struct fimc_ctx
*ctx)
void fimc_capture_irq_handler(struct fimc_dev *fimc, int deq_buf)
{
- struct v4l2_subdev *csis = fimc->pipeline.subdevs[IDX_CSIS];
+ struct v4l2_subdev *csis;
struct fimc_vid_cap *cap = &fimc->vid_cap;
struct fimc_frame *f = &cap->ctx->d_frame;
struct fimc_vid_buffer *v_buf;
struct timeval *tv;
struct timespec ts;
+ csis = exynos_pipeline_get_subdev(fimc->pipeline_ops,
+ get_subdev_csis, &fimc->pipeline);
+
if (test_and_clear_bit(ST_CAPT_SHUT, &fimc->state)) {
wake_up(&fimc->irq_queue);
goto done;
@@ -286,7 +291,7 @@ static int start_streaming(struct vb2_queue *q, unsigned
int count)
fimc_activate_capture(ctx);
if (!test_and_set_bit(ST_CAPT_ISP_STREAM, &fimc->state))
- fimc_pipeline_call(fimc, set_stream,
+ exynos_pipeline_call(fimc, set_stream,
&fimc->pipeline, 1);
}
@@ -311,7 +316,7 @@ int fimc_capture_suspend(struct fimc_dev *fimc)
int ret = fimc_stop_capture(fimc, suspend);
if (ret)
return ret;
- return fimc_pipeline_call(fimc, close, &fimc->pipeline);
+ return exynos_pipeline_call(fimc, close, &fimc->pipeline);
}
static void buffer_queue(struct vb2_buffer *vb);
@@ -327,7 +332,7 @@ int fimc_capture_resume(struct fimc_dev *fimc)
INIT_LIST_HEAD(&fimc->vid_cap.active_buf_q);
vid_cap->buf_index = 0;
- fimc_pipeline_call(fimc, open, &fimc->pipeline,
+ exynos_pipeline_call(fimc, open, &fimc->pipeline,
&vid_cap->vfd.entity, false);
fimc_capture_hw_init(fimc);
@@ -447,7 +452,7 @@ static void buffer_queue(struct vb2_buffer *vb)
spin_unlock_irqrestore(&fimc->slock, flags);
if (!test_and_set_bit(ST_CAPT_ISP_STREAM, &fimc->state))
- fimc_pipeline_call(fimc, set_stream,
+ exynos_pipeline_call(fimc, set_stream,
&fimc->pipeline, 1);
return;
}
@@ -486,9 +491,12 @@ static struct vb2_ops fimc_capture_qops = {
int fimc_capture_ctrls_create(struct fimc_dev *fimc)
{
struct fimc_vid_cap *vid_cap = &fimc->vid_cap;
- struct v4l2_subdev *sensor = fimc->pipeline.subdevs[IDX_SENSOR];
+ struct v4l2_subdev *sensor;
int ret;
+ sensor = exynos_pipeline_get_subdev(fimc->pipeline_ops,
+
[RFC 00/12] Adding media device driver for Exynos imaging subsystem
The following patchset features: 1] Creating a common pipeline framework which can be used by all Exynos series SoCs for developing media device drivers. 2] Modified the existing fimc-mdevice for exynos4 to use the common pipeline framework. 3] Adding of media device driver for Exynos5 Imaging subsystem. 4] Upgrading mipi-csis and fimc-lite drivers for Exynos5 SoCs. 5] Adding DT support to m5mols driver and tested with Exynos5 media device driver. Current changes are not tested on exynos4 series SoCs. Current media device driver only support one pipeline (pipeline0) which consists of Sensor --> MIPI-CSIS --> FIMC-LITE Sensor --> FIMC-LITE G-Scaler support to pipeline0 will be added later. Once the fimc-is device driver is posted, one more pipeline (pipeline1) will be added for exynos5 media device driver for fimc-is sub-devices. This patchset is rebased on: git://linuxtv.org/media_tree.git:staging/for_v3.9 This patchset depends on: from Thomas Abraham: [1] pinctrl: exynos: add support for Samsung's Exynos5250 [2] ARM: dts: add pinctrl nodes for Exynos5250 SoC from Sylwester Nawrocki: [1] Device tree support for Exynos SoC camera subsystem Shaik Ameer Basha (12): media: s5p-fimc: modify existing mdev to use common pipeline fimc-lite: Adding Exynos5 compatibility to fimc-lite driver media: fimc-lite: Adding support for Exynos5 s5p-csis: Adding Exynos5250 compatibility ARM: EXYNOS: Add devicetree node for mipi-csis driver for exynos5 ARM: EXYNOS: Add devicetree node for FIMC-LITE driver for exynos5 media: exynos5-is: Adding media device driver for exynos5 ARM: dts: add camera specific pinctrl nodes for Exynos5250 SoC ARM: dts: Adding pinctrl support to Exynos5250 i2c nodes ARM: dts: Adding media device nodes to Exynos5 SoCs media: m5mols: Adding dt support to m5mols driver ARM: dts: Add camera node to exynos5250-smdk5250.dts arch/arm/boot/dts/exynos5250-pinctrl.dtsi| 41 + arch/arm/boot/dts/exynos5250-smdk5250.dts| 65 +- arch/arm/boot/dts/exynos5250.dtsi| 54 + arch/arm/mach-exynos/clock-exynos5.c | 20 +- arch/arm/mach-exynos/include/mach/map.h |7 + arch/arm/mach-exynos/mach-exynos5-dt.c | 10 + drivers/media/i2c/m5mols/m5mols_core.c | 54 +- drivers/media/platform/Kconfig |1 + drivers/media/platform/Makefile |1 + drivers/media/platform/exynos5-is/Kconfig|7 + drivers/media/platform/exynos5-is/Makefile |4 + drivers/media/platform/exynos5-is/exynos5-mdev.c | 1309 ++ drivers/media/platform/exynos5-is/exynos5-mdev.h | 107 ++ drivers/media/platform/s5p-fimc/fimc-capture.c | 96 +- drivers/media/platform/s5p-fimc/fimc-core.h |4 +- drivers/media/platform/s5p-fimc/fimc-lite-reg.c | 16 +- drivers/media/platform/s5p-fimc/fimc-lite-reg.h | 41 +- drivers/media/platform/s5p-fimc/fimc-lite.c | 292 - drivers/media/platform/s5p-fimc/fimc-lite.h | 12 +- drivers/media/platform/s5p-fimc/fimc-mdevice.c | 186 ++- drivers/media/platform/s5p-fimc/fimc-mdevice.h | 41 +- drivers/media/platform/s5p-fimc/mipi-csis.c |1 + include/media/s5p_fimc.h | 66 +- 23 files changed, 2261 insertions(+), 174 deletions(-) create mode 100644 drivers/media/platform/exynos5-is/Kconfig create mode 100644 drivers/media/platform/exynos5-is/Makefile create mode 100644 drivers/media/platform/exynos5-is/exynos5-mdev.c create mode 100644 drivers/media/platform/exynos5-is/exynos5-mdev.h -- 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] ASoC: samsung: let device core setup the default pin configuration
On 6 March 2013 17:19, Mark Brown wrote: > On Wed, Mar 06, 2013 at 12:42:09PM +0100, Heiko Stübner wrote: > >> What is going away is the deprecated non-pinctrl way to setup the pins on dt >> platforms. > > OK, can we have a changelog improvement please? I didn't read the patch > properly because the changelog said it would break my primary > development system. Ok. I will repost again with additional details in the changelog. -- 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: let device core setup the default pin configuration
On Wed, Mar 06, 2013 at 12:42:09PM +0100, Heiko Stübner wrote: > What is going away is the deprecated non-pinctrl way to setup the pins on dt > platforms. OK, can we have a changelog improvement please? I didn't read the patch properly because the changelog said it would break my primary development system. signature.asc Description: Digital signature
[PATCH] mmc: dwmmc: let device core setup the default pin configuration
With device core now able to setup the default pin configuration,
the pin configuration code based on the deprecated Samsung specific
gpio bindings is removed.
Signed-off-by: Thomas Abraham
---
drivers/mmc/host/dw_mmc-exynos.c | 38 --
1 files changed, 0 insertions(+), 38 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index 72fd0f2..467d043 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -152,43 +152,6 @@ static int dw_mci_exynos_parse_dt(struct dw_mci *host)
return 0;
}
-static int dw_mci_exynos_setup_bus(struct dw_mci *host,
- struct device_node *slot_np, u8 bus_width)
-{
- int idx, gpio, ret;
-
- if (!slot_np)
- return -EINVAL;
-
- /* cmd + clock + bus-width pins */
- for (idx = 0; idx < NUM_PINS(bus_width); idx++) {
- gpio = of_get_gpio(slot_np, idx);
- if (!gpio_is_valid(gpio)) {
- dev_err(host->dev, "invalid gpio: %d\n", gpio);
- return -EINVAL;
- }
-
- ret = devm_gpio_request(host->dev, gpio, "dw-mci-bus");
- if (ret) {
- dev_err(host->dev, "gpio [%d] request failed\n", gpio);
- return -EBUSY;
- }
- }
-
- 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"))
- 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 |
@@ -205,7 +168,6 @@ static const struct dw_mci_drv_data exynos5250_drv_data = {
.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[] = {
--
1.6.6.rc2
--
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: let device core setup the default pin configuration
Am Mittwoch, 6. März 2013, 12:37:43 schrieb Mark Brown:
> On Wed, Mar 06, 2013 at 05:25:51PM +0530, Thomas Abraham wrote:
> > With device core now able to setup the default pin configuration,
> > the pin configuration code based on the deprecated Samsung specific
> > gpio bindings in i2s driver is removed.
>
> There's rather a lot of non-DT Samsung platforms...
I think the real non-dt platforms won't be affected.
+ if (i2s_pdata->cfg_gpio && i2s_pdata->cfg_gpio(pdev)) {
+ dev_err(&pdev->dev, "Unable to configure gpio\n");
+ ret = -EINVAL;
+ goto err;
is still there for them.
What is going away is the deprecated non-pinctrl way to setup the pins on dt
platforms.
--
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: let device core setup the default pin configuration
On Wed, Mar 06, 2013 at 05:25:51PM +0530, Thomas Abraham wrote: > With device core now able to setup the default pin configuration, > the pin configuration code based on the deprecated Samsung specific > gpio bindings in i2s driver is removed. There's rather a lot of non-DT Samsung platforms... signature.asc Description: Digital signature
[PATCH] ASoC: samsung: let device core setup the default pin configuration
With device core now able to setup the default pin configuration,
the pin configuration code based on the deprecated Samsung specific
gpio bindings in i2s driver is removed.
Signed-off-by: Thomas Abraham
---
.../devicetree/bindings/sound/samsung-i2s.txt | 30 +
sound/soc/samsung/i2s.c| 67 +--
2 files changed, 8 insertions(+), 89 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.txt
b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
index 3070046..1db65e5 100644
--- a/Documentation/devicetree/bindings/sound/samsung-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
@@ -20,23 +20,11 @@ Optional SoC Specific Properties:
then this flag is enabled.
- samsung,idma-addr: Internal DMA register base address of the audio
sub system(used in secondary sound source).
-
-Required Board Specific Properties:
-
-- gpios: The gpio specifier for data out,data in, LRCLK, CDCLK and SCLK
- interface lines. The format of the gpio specifier depends on the gpio
- controller.
- The syntax of samsung gpio specifier is
- <[phandle of the gpio controller node]
-[pin number within the gpio controller]
-[mux function]
-[flags and pull up/down]
-[drive strength]>
+- pinctrl-0: Should specify pin control groups used for this controller.
+- pinctrl-names: Should contain only one value - "default".
Example:
-- SoC Specific Portion:
-
i2s@0383 {
compatible = "samsung,i2s-v5";
reg = <0x0383 0x100>;
@@ -48,16 +36,6 @@ i2s@0383 {
samsung,supports-rstclr;
samsung,supports-secdai;
samsung,idma-addr = <0x0300>;
-};
-
-- Board Specific Portion:
-
-i2s@0383 {
- gpios = <&gpz 0 2 0 0>, /* I2S_0_SCLK */
- <&gpz 1 2 0 0>, /* I2S_0_CDCLK */
- <&gpz 2 2 0 0>, /* I2S_0_LRCK */
- <&gpz 3 2 0 0>, /* I2S_0_SDI */
- <&gpz 4 2 0 0>, /* I2S_0_SDO[1] */
- <&gpz 5 2 0 0>, /* I2S_0_SDO[2] */
- <&gpz 6 2 0 0>; /* I2S_0_SDO[3] */
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s0_bus>;
};
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index d7231e3..f982a83 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -16,7 +16,6 @@
#include
#include
#include
-#include
#include
#include
@@ -79,7 +78,6 @@ struct i2s_dai {
u32 suspend_i2smod;
u32 suspend_i2scon;
u32 suspend_i2spsr;
- unsigned long gpios[7]; /* i2s gpio line numbers */
};
/* Lock for cross i/f checks */
@@ -1009,52 +1007,6 @@ static struct i2s_dai *i2s_alloc_dai(struct
platform_device *pdev, bool sec)
return i2s;
}
-#ifdef CONFIG_OF
-static int samsung_i2s_parse_dt_gpio(struct i2s_dai *i2s)
-{
- struct device *dev = &i2s->pdev->dev;
- int index, gpio, ret;
-
- for (index = 0; index < 7; index++) {
- gpio = of_get_gpio(dev->of_node, index);
- if (!gpio_is_valid(gpio)) {
- dev_err(dev, "invalid gpio[%d]: %d\n", index, gpio);
- goto free_gpio;
- }
-
- ret = gpio_request(gpio, dev_name(dev));
- if (ret) {
- dev_err(dev, "gpio [%d] request failed\n", gpio);
- goto free_gpio;
- }
- i2s->gpios[index] = gpio;
- }
- return 0;
-
-free_gpio:
- while (--index >= 0)
- gpio_free(i2s->gpios[index]);
- return -EINVAL;
-}
-
-static void samsung_i2s_dt_gpio_free(struct i2s_dai *i2s)
-{
- unsigned int index;
- for (index = 0; index < 7; index++)
- gpio_free(i2s->gpios[index]);
-}
-#else
-static int samsung_i2s_parse_dt_gpio(struct i2s_dai *dai)
-{
- return -EINVAL;
-}
-
-static void samsung_i2s_dt_gpio_free(struct i2s_dai *dai)
-{
-}
-
-#endif
-
static const struct of_device_id exynos_i2s_match[];
static inline int samsung_i2s_get_driver_data(struct platform_device *pdev)
@@ -1223,18 +1175,10 @@ static int samsung_i2s_probe(struct platform_device
*pdev)
pri_dai->sec_dai = sec_dai;
}
- if (np) {
- if (samsung_i2s_parse_dt_gpio(pri_dai)) {
- dev_err(&pdev->dev, "Unable to configure gpio\n");
- ret = -EINVAL;
- goto err;
- }
- } else {
- if (i2s_pdata->cfg_gpio && i2s_pdata->cfg_gpio(pdev)) {
- dev_err(&pdev->dev, "Unable to configure gpio\n");
- ret = -EINVAL;
- goto err;
- }
+ if (i2s_pdata->cfg_gpio && i2s_pdata->cfg_gpio(pdev)) {
+ dev_err(&pdev->dev, "Unable to configure gpio\n");
+ ret = -EINVAL;
+ goto err;
}
snd_soc_register_dai(&pr
[PATCH] input: samsung-keypad: let device core setup the default pin configuration
With device core now able to setup the default pin configuration,
the pin configuration code based on the deprecated Samsung specific
gpio bindings is removed.
Signed-off-by: Thomas Abraham
---
.../devicetree/bindings/input/samsung-keypad.txt | 25 ++
drivers/input/keyboard/samsung-keypad.c| 52 +---
2 files changed, 7 insertions(+), 70 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/samsung-keypad.txt
b/Documentation/devicetree/bindings/input/samsung-keypad.txt
index ce3e394..73ad847 100644
--- a/Documentation/devicetree/bindings/input/samsung-keypad.txt
+++ b/Documentation/devicetree/bindings/input/samsung-keypad.txt
@@ -25,14 +25,6 @@ Required Board Specific Properties:
- samsung,keypad-num-columns: Number of column lines connected to the
keypad controller.
-- row-gpios: List of gpios used as row lines. The gpio specifier for
- this property depends on the gpio controller to which these row lines
- are connected.
-
-- col-gpios: List of gpios used as column lines. The gpio specifier for
- this property depends on the gpio controller to which these column
- lines are connected.
-
- Keys represented as child nodes: Each key connected to the keypad
controller is represented as a child node to the keypad controller
device node and should include the following properties.
@@ -41,6 +33,9 @@ Required Board Specific Properties:
- linux,code: the key-code to be reported when the key is pressed
and released.
+- pinctrl-0: Should specify pin control groups used for this controller.
+- pinctrl-names: Should contain only one value - "default".
+
Optional Properties specific to linux:
- linux,keypad-no-autorepeat: do no enable autorepeat feature.
- linux,keypad-wakeup: use any event on keypad as wakeup event.
@@ -55,18 +50,8 @@ Example:
samsung,keypad-num-columns = <8>;
linux,input-no-autorepeat;
linux,input-wakeup;
-
- row-gpios = <&gpx2 0 3 3 0
-&gpx2 1 3 3 0>;
-
- col-gpios = <&gpx1 0 3 0 0
-&gpx1 1 3 0 0
-&gpx1 2 3 0 0
-&gpx1 3 3 0 0
-&gpx1 4 3 0 0
-&gpx1 5 3 0 0
-&gpx1 6 3 0 0
-&gpx1 7 3 0 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&keypad_rows &keypad_columns>;
key_1 {
keypad,row = <0>;
diff --git a/drivers/input/keyboard/samsung-keypad.c
b/drivers/input/keyboard/samsung-keypad.c
index 22e357b..03bdad7 100644
--- a/drivers/input/keyboard/samsung-keypad.c
+++ b/drivers/input/keyboard/samsung-keypad.c
@@ -24,7 +24,6 @@
#include
#include
#include
-#include
#include
#include
@@ -79,10 +78,6 @@ struct samsung_keypad {
unsigned int rows;
unsigned int cols;
unsigned int row_state[SAMSUNG_MAX_COLS];
-#ifdef CONFIG_OF
- int row_gpios[SAMSUNG_MAX_ROWS];
- int col_gpios[SAMSUNG_MAX_COLS];
-#endif
unsigned short keycodes[];
};
@@ -304,45 +299,6 @@ static struct samsung_keypad_platdata
*samsung_keypad_parse_dt(
return pdata;
}
-
-static void samsung_keypad_parse_dt_gpio(struct device *dev,
- struct samsung_keypad *keypad)
-{
- struct device_node *np = dev->of_node;
- int gpio, error, row, col;
-
- for (row = 0; row < keypad->rows; row++) {
- gpio = of_get_named_gpio(np, "row-gpios", row);
- keypad->row_gpios[row] = gpio;
- if (!gpio_is_valid(gpio)) {
- dev_err(dev, "keypad row[%d]: invalid gpio %d\n",
- row, gpio);
- continue;
- }
-
- error = devm_gpio_request(dev, gpio, "keypad-row");
- if (error)
- dev_err(dev,
- "keypad row[%d] gpio request failed: %d\n",
- row, error);
- }
-
- for (col = 0; col < keypad->cols; col++) {
- gpio = of_get_named_gpio(np, "col-gpios", col);
- keypad->col_gpios[col] = gpio;
- if (!gpio_is_valid(gpio)) {
- dev_err(dev, "keypad column[%d]: invalid gpio %d\n",
- col, gpio);
- continue;
- }
-
- error = devm_gpio_request(dev, gpio, "keypad-col");
- if (error)
- dev_err(dev,
- "keypad column[%d] gpio request failed: %d\n",
- col, error);
- }
-}
#else
static
struct samsung_keypad_platdata *samsung_keypad_parse_dt(struct device *dev)
@@ -424,15 +380,11 @@ static int samsung_keypad_probe(struct platform_device
*pde
[PATCH] spi: s3c64xx: let device core setup the default pin configuration
With device core now able to setup the default pin configuration,
the pin configuration code based on the deprecated Samsung specific
gpio bindings is removed.
Signed-off-by: Thomas Abraham
---
.../devicetree/bindings/spi/spi-samsung.txt|8 +--
drivers/spi/spi-s3c64xx.c | 66 +--
2 files changed, 6 insertions(+), 68 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/spi-samsung.txt
b/Documentation/devicetree/bindings/spi/spi-samsung.txt
index a15ffed..86aa061 100644
--- a/Documentation/devicetree/bindings/spi/spi-samsung.txt
+++ b/Documentation/devicetree/bindings/spi/spi-samsung.txt
@@ -31,9 +31,6 @@ Required Board Specific Properties:
- #address-cells: should be 1.
- #size-cells: should be 0.
-- gpios: The gpio specifier for clock, mosi and miso interface lines (in the
- order specified). The format of the gpio specifier depends on the gpio
- controller.
Optional Board Specific Properties:
@@ -86,9 +83,8 @@ Example:
spi_0: spi@12d2 {
#address-cells = <1>;
#size-cells = <0>;
- gpios = <&gpa2 4 2 3 0>,
- <&gpa2 6 2 3 0>,
- <&gpa2 7 2 3 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_bus>;
w25q80bw@0 {
#address-cells = <1>;
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index e862ab8..8537b17 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1052,41 +1052,6 @@ static void s3c64xx_spi_hwinit(struct
s3c64xx_spi_driver_data *sdd, int channel)
}
#ifdef CONFIG_OF
-static int s3c64xx_spi_parse_dt_gpio(struct s3c64xx_spi_driver_data *sdd)
-{
- struct device *dev = &sdd->pdev->dev;
- int idx, gpio, ret;
-
- /* find gpios for mosi, miso and clock lines */
- for (idx = 0; idx < 3; idx++) {
- gpio = of_get_gpio(dev->of_node, idx);
- if (!gpio_is_valid(gpio)) {
- dev_err(dev, "invalid gpio[%d]: %d\n", idx, gpio);
- goto free_gpio;
- }
- sdd->gpios[idx] = gpio;
- ret = gpio_request(gpio, "spi-bus");
- if (ret) {
- dev_err(dev, "gpio [%d] request failed: %d\n",
- gpio, ret);
- goto free_gpio;
- }
- }
- return 0;
-
-free_gpio:
- while (--idx >= 0)
- gpio_free(sdd->gpios[idx]);
- return -EINVAL;
-}
-
-static void s3c64xx_spi_dt_gpio_free(struct s3c64xx_spi_driver_data *sdd)
-{
- unsigned int idx;
- for (idx = 0; idx < 3; idx++)
- gpio_free(sdd->gpios[idx]);
-}
-
static struct s3c64xx_spi_info *s3c64xx_spi_parse_dt(struct device *dev)
{
struct s3c64xx_spi_info *sci;
@@ -1119,15 +1084,6 @@ static struct s3c64xx_spi_info
*s3c64xx_spi_parse_dt(struct device *dev)
{
return dev->platform_data;
}
-
-static int s3c64xx_spi_parse_dt_gpio(struct s3c64xx_spi_driver_data *sdd)
-{
- return -EINVAL;
-}
-
-static void s3c64xx_spi_dt_gpio_free(struct s3c64xx_spi_driver_data *sdd)
-{
-}
#endif
static const struct of_device_id s3c64xx_spi_dt_match[];
@@ -1247,10 +1203,7 @@ static int s3c64xx_spi_probe(struct platform_device
*pdev)
goto err0;
}
- if (!sci->cfg_gpio && pdev->dev.of_node) {
- if (s3c64xx_spi_parse_dt_gpio(sdd))
- return -EBUSY;
- } else if (sci->cfg_gpio == NULL || sci->cfg_gpio()) {
+ if (sci->cfg_gpio && sci->cfg_gpio()) {
dev_err(&pdev->dev, "Unable to config gpio\n");
ret = -EBUSY;
goto err0;
@@ -1261,13 +1214,13 @@ static int s3c64xx_spi_probe(struct platform_device
*pdev)
if (IS_ERR(sdd->clk)) {
dev_err(&pdev->dev, "Unable to acquire clock 'spi'\n");
ret = PTR_ERR(sdd->clk);
- goto err1;
+ goto err0;
}
if (clk_prepare_enable(sdd->clk)) {
dev_err(&pdev->dev, "Couldn't enable clock 'spi'\n");
ret = -EBUSY;
- goto err1;
+ goto err0;
}
sprintf(clk_name, "spi_busclk%d", sci->src_clk_nr);
@@ -1324,9 +1277,6 @@ err3:
clk_disable_unprepare(sdd->src_clk);
err2:
clk_disable_unprepare(sdd->clk);
-err1:
- if (!sdd->cntrlr_info->cfg_gpio && pdev->dev.of_node)
- s3c64xx_spi_dt_gpio_free(sdd);
err0:
platform_set_drvdata(pdev, NULL);
spi_master_put(master);
@@ -1349,9 +1299,6 @@ static int s3c64xx_spi_remove(struct platform_device
*pdev)
clk_disable_unprepare(sdd->clk);
- if (!sdd->cntrlr_info->cfg_gpio && pdev->dev.of_node)
- s3c64xx_spi_dt_gpio_free(sdd);
-
platform_set_drvdata(pdev, NULL);
spi_master_put(maste
[PATCH] mmc: sdhci-s3c: let device core setup the default pin configuration
With device core now able to setup the default pin configuration,
the call to devm_pinctrl_get_select_default can be removed. And
the pin configuration code based on the deprecated Samsung specific
gpio bindings is also removed.
Signed-off-by: Thomas Abraham
---
.../devicetree/bindings/mmc/samsung-sdhci.txt | 35 +-
drivers/mmc/host/sdhci-s3c.c | 71 ++-
2 files changed, 12 insertions(+), 94 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
index 3b3a1ee..328e990 100644
--- a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
@@ -5,13 +5,6 @@ MMC, SD and eMMC storage mediums. This file documents
differences between the
core mmc properties described by mmc.txt and the properties used by the
Samsung implmentation of the SDHCI controller.
-Note: The mmc core bindings documentation states that if none of the core
-card-detect bindings are used, then the standard sdhci card detect mechanism
-is used. The Samsung's SDHCI controller bindings extends this as listed below.
-
-[A] The property "samsung,cd-pinmux-gpio" can be used as stated in the
-"Optional Board Specific Properties" section below.
-
Required SoC Specific Properties:
- compatible: should be one of the following
- "samsung,s3c6410-sdhci": For controllers compatible with s3c6410 sdhci
@@ -20,18 +13,8 @@ Required SoC Specific Properties:
controller.
Required Board Specific Properties:
-- Samsung GPIO variant (will be completely replaced by pinctrl):
- - gpios: Should specify the gpios used for clock, command and data lines. The
-gpio specifier format depends on the gpio controller.
-- Pinctrl variant (preferred if available):
- - pinctrl-0: Should specify pin control groups used for this controller.
- - pinctrl-names: Should contain only one value - "default".
-
-Optional Board Specific Properties:
-- samsung,cd-pinmux-gpio: Specifies the card detect line that is routed
- through a pinmux to the card-detect pin of the card slot. This property
- should be used only if none of the mmc core card-detect properties are
- used. Only for Samsung GPIO variant.
+- pinctrl-0: Should specify pin control groups used for this controller.
+- pinctrl-names: Should contain only one value - "default".
Example:
sdhci@1253 {
@@ -39,19 +22,9 @@ Example:
reg = <0x1253 0x100>;
interrupts = <0 75 0>;
bus-width = <4>;
- cd-gpios = <&gpk2 2 2 3 3>;
-
- /* Samsung GPIO variant */
- gpios = <&gpk2 0 2 0 3>, /* clock line */
- <&gpk2 1 2 0 3>, /* command line */
- <&gpk2 3 2 3 3>, /* data line 0 */
- <&gpk2 4 2 3 3>, /* data line 1 */
- <&gpk2 5 2 3 3>, /* data line 2 */
- <&gpk2 6 2 3 3>; /* data line 3 */
-
- /* Pinctrl variant */
- pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4>;
+ cd-gpios = <&gpk2 2 0>;
pinctrl-names = "default";
+ pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4>;
};
Note: This example shows both SoC specific and board specific properties
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 7363efe..86e0bd7 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -24,7 +24,6 @@
#include
#include
#include
-#include
#include
@@ -45,7 +44,6 @@
* @ioarea: The resource created when we claimed the IO area.
* @pdata: The platform data for this controller.
* @cur_clk: The index of the current bus clock.
- * @gpios: List of gpio numbers parsed from device tree.
* @clk_io: The clock for the internal bus interface.
* @clk_bus: The clocks that are available for the SD/MMC bus clock.
*/
@@ -57,8 +55,6 @@ struct sdhci_s3c {
unsigned intcur_clk;
int ext_cd_irq;
int ext_cd_gpio;
- int *gpios;
- struct pinctrl *pctrl;
struct clk *clk_io;
struct clk *clk_bus[MAX_BUS_CLK];
@@ -447,88 +443,39 @@ static int sdhci_s3c_parse_dt(struct device *dev,
struct device_node *node = dev->of_node;
struct sdhci_s3c *ourhost = to_s3c(host);
u32 max_width;
- int gpio, cnt, ret;
+ int gpio;
/* if the bus-width property is not specified, assume width as 1 */
if (of_property_read_u32(node, "bus-width", &max_width))
max_width = 1;
pdata->max_width = max_width;
- ourhost->gpios = devm_kzalloc(dev, NUM_GPIOS(pdata->max_width) *
- sizeof(int), GFP_KERNEL);
- if (!ourhost->gpios)
- return -ENOMEM;
[PATCH v2 1/3] pinctrl: exynos: add exynos5250 SoC specific data
Add Samsung Exynos5250 SoC specific data to enable pinctrl support for
all platforms based on Exynos5250.
Signed-off-by: Thomas Abraham
Reviewed-by: Tomasz Figa
Acked-by: Linus Walleij
---
drivers/pinctrl/pinctrl-exynos.c | 108 +
drivers/pinctrl/pinctrl-samsung.c |2 +
drivers/pinctrl/pinctrl-samsung.h |1 +
3 files changed, 111 insertions(+), 0 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-exynos.c b/drivers/pinctrl/pinctrl-exynos.c
index 538b9dd..8738933 100644
--- a/drivers/pinctrl/pinctrl-exynos.c
+++ b/drivers/pinctrl/pinctrl-exynos.c
@@ -677,3 +677,111 @@ struct samsung_pin_ctrl exynos4x12_pin_ctrl[] = {
.label = "exynos4x12-gpio-ctrl3",
},
};
+
+/* pin banks of exynos5250 pin-controller 0 */
+static struct samsung_pin_bank exynos5250_pin_banks0[] = {
+ EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpa0", 0x00),
+ EXYNOS_PIN_BANK_EINTG(6, 0x020, "gpa1", 0x04),
+ EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpa2", 0x08),
+ EXYNOS_PIN_BANK_EINTG(5, 0x060, "gpb0", 0x0c),
+ EXYNOS_PIN_BANK_EINTG(5, 0x080, "gpb1", 0x10),
+ EXYNOS_PIN_BANK_EINTG(4, 0x0A0, "gpb2", 0x14),
+ EXYNOS_PIN_BANK_EINTG(4, 0x0C0, "gpb3", 0x18),
+ EXYNOS_PIN_BANK_EINTG(7, 0x0E0, "gpc0", 0x1c),
+ EXYNOS_PIN_BANK_EINTG(4, 0x100, "gpc1", 0x20),
+ EXYNOS_PIN_BANK_EINTG(7, 0x120, "gpc2", 0x24),
+ EXYNOS_PIN_BANK_EINTG(7, 0x140, "gpc3", 0x28),
+ EXYNOS_PIN_BANK_EINTG(4, 0x160, "gpd0", 0x2c),
+ EXYNOS_PIN_BANK_EINTG(8, 0x180, "gpd1", 0x30),
+ EXYNOS_PIN_BANK_EINTG(7, 0x2E0, "gpc4", 0x34),
+ EXYNOS_PIN_BANK_EINTN(6, 0x1A0, "gpy0"),
+ EXYNOS_PIN_BANK_EINTN(4, 0x1C0, "gpy1"),
+ EXYNOS_PIN_BANK_EINTN(6, 0x1E0, "gpy2"),
+ EXYNOS_PIN_BANK_EINTN(8, 0x200, "gpy3"),
+ EXYNOS_PIN_BANK_EINTN(8, 0x220, "gpy4"),
+ EXYNOS_PIN_BANK_EINTN(8, 0x240, "gpy5"),
+ EXYNOS_PIN_BANK_EINTN(8, 0x260, "gpy6"),
+ EXYNOS_PIN_BANK_EINTW(8, 0xC00, "gpx0", 0x00),
+ EXYNOS_PIN_BANK_EINTW(8, 0xC20, "gpx1", 0x04),
+ EXYNOS_PIN_BANK_EINTW(8, 0xC40, "gpx2", 0x08),
+ EXYNOS_PIN_BANK_EINTW(8, 0xC60, "gpx3", 0x0c),
+};
+
+/* pin banks of exynos5250 pin-controller 1 */
+static struct samsung_pin_bank exynos5250_pin_banks1[] = {
+ EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpe0", 0x00),
+ EXYNOS_PIN_BANK_EINTG(2, 0x020, "gpe1", 0x04),
+ EXYNOS_PIN_BANK_EINTG(4, 0x040, "gpf0", 0x08),
+ EXYNOS_PIN_BANK_EINTG(4, 0x060, "gpf1", 0x0c),
+ EXYNOS_PIN_BANK_EINTG(8, 0x080, "gpg0", 0x10),
+ EXYNOS_PIN_BANK_EINTG(8, 0x0A0, "gpg1", 0x14),
+ EXYNOS_PIN_BANK_EINTG(2, 0x0C0, "gpg2", 0x18),
+ EXYNOS_PIN_BANK_EINTG(4, 0x0E0, "gph0", 0x1c),
+ EXYNOS_PIN_BANK_EINTG(8, 0x100, "gph1", 0x20),
+};
+
+/* pin banks of exynos5250 pin-controller 2 */
+static struct samsung_pin_bank exynos5250_pin_banks2[] = {
+ EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpv0", 0x00),
+ EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpv1", 0x04),
+ EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpv2", 0x08),
+ EXYNOS_PIN_BANK_EINTG(8, 0x080, "gpv3", 0x0c),
+ EXYNOS_PIN_BANK_EINTG(2, 0x0C0, "gpv4", 0x10),
+};
+
+/* pin banks of exynos5250 pin-controller 3 */
+static struct samsung_pin_bank exynos5250_pin_banks3[] = {
+ EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpz", 0x00),
+};
+
+/*
+ * Samsung pinctrl driver data for Exynos5250 SoC. Exynos5250 SoC includes
+ * four gpio/pin-mux/pinconfig controllers.
+ */
+struct samsung_pin_ctrl exynos5250_pin_ctrl[] = {
+ {
+ /* pin-controller instance 0 data */
+ .pin_banks = exynos5250_pin_banks0,
+ .nr_banks = ARRAY_SIZE(exynos5250_pin_banks0),
+ .geint_con = EXYNOS_GPIO_ECON_OFFSET,
+ .geint_mask = EXYNOS_GPIO_EMASK_OFFSET,
+ .geint_pend = EXYNOS_GPIO_EPEND_OFFSET,
+ .weint_con = EXYNOS_WKUP_ECON_OFFSET,
+ .weint_mask = EXYNOS_WKUP_EMASK_OFFSET,
+ .weint_pend = EXYNOS_WKUP_EPEND_OFFSET,
+ .svc= EXYNOS_SVC_OFFSET,
+ .eint_gpio_init = exynos_eint_gpio_init,
+ .eint_wkup_init = exynos_eint_wkup_init,
+ .label = "exynos5250-gpio-ctrl0",
+ }, {
+ /* pin-controller instance 1 data */
+ .pin_banks = exynos5250_pin_banks1,
+ .nr_banks = ARRAY_SIZE(exynos5250_pin_banks1),
+ .geint_con = EXYNOS_GPIO_ECON_OFFSET,
+ .geint_mask = EXYNOS_GPIO_EMASK_OFFSET,
+ .geint_pend = EXYNOS_GPIO_EPEND_OFFSET,
+ .svc= EXYNOS_SVC_OFFSET,
+ .eint_gpio_init = exynos_eint_gpio_init,
+ .label = "exynos5250-gpio-ctrl1",
+ }, {
+ /* pin-controller instance 2 data */
+ .pin_banks = exynos5250_pin_banks2,
+ .n
[PATCH v2 3/3] arm: exynos: skip wakeup interrupt registration for exynos5250 if pinctrl is enabled
Skip the wakeup interrupt registration for Exynos5250 if pinctrl support
is enabled for Exynos5250.
Signed-off-by: Thomas Abraham
Reviewed-by: Tomasz Figa
Acked-by: Linus Walleij
---
arch/arm/mach-exynos/common.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index d63d399..bdd9579 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -822,6 +822,7 @@ static int __init exynos_init_irq_eint(void)
static const struct of_device_id exynos_pinctrl_ids[] = {
{ .compatible = "samsung,exynos4210-pinctrl", },
{ .compatible = "samsung,exynos4x12-pinctrl", },
+ { .compatible = "samsung,exynos5250-pinctrl", },
};
struct device_node *pctrl_np, *wkup_np;
const char *wkup_compat = "samsung,exynos4210-wakeup-eint";
--
1.6.6.rc2
--
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 v2 2/3] gpio: samsung: skip gpiolib registration if pinctrl support is enabled for exynos5250
Skip exynos5250 gpiolib registration if pinctrl support for exynos5250
is enabled.
Signed-off-by: Thomas Abraham
Reviewed-by: Tomasz Figa
Acked-by: Linus Walleij
---
drivers/gpio/gpio-samsung.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index b3643ff..49b4292 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -3024,6 +3024,7 @@ static __init int samsung_gpiolib_init(void)
static const struct of_device_id exynos_pinctrl_ids[] = {
{ .compatible = "samsung,exynos4210-pinctrl", },
{ .compatible = "samsung,exynos4x12-pinctrl", },
+ { .compatible = "samsung,exynos5250-pinctrl", },
{ .compatible = "samsung,exynos5440-pinctrl", },
};
for_each_matching_node(pctrl_np, exynos_pinctrl_ids)
--
1.6.6.rc2
--
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 v2 0/3] pinctrl: exynos: add support for Samsung's Exynos5250
Changes since v1: - Change the compatible string from "samsung,pinctrl-exynos5250" to "samsung,exynos5250-pinctrl". - Rebased to v3.9-rc1 This patch series add pinctrl driver support for Samsung's Exynos5250 SoC. The first patch adds the required Exynos5250 SoC specific data which is used by the Samsung pinctrl driver to setup the pinctrl/pinmux/eint controllers. The second and third patches skips the wakeup interrupt and gpiolib registration if the pinctrl support is enabled for Exynos5250. Thomas Abraham (3): pinctrl: exynos: add exynos5250 SoC specific data gpio: samsung: skip gpiolib registration if pinctrl support is enabled for exynos5250 arm: exynos: skip wakeup interrupt registration for exynos5250 if pinctrl is enabled arch/arm/mach-exynos/common.c |1 + drivers/gpio/gpio-samsung.c |1 + drivers/pinctrl/pinctrl-exynos.c | 108 + drivers/pinctrl/pinctrl-samsung.c |2 + drivers/pinctrl/pinctrl-samsung.h |1 + 5 files changed, 113 insertions(+), 0 deletions(-) -- 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] ARM: drop "select HAVE_SCHED_CLOCK"
The Kconfig symbol HAVE_SCHED_CLOCK got removed in v3.4, with commit
6905a65879b51d326396e63dfea40861a30bc17f ("ARM: Make the sched_clock
framework mandatory"). Drop the last two select statements for that
symbol too. They're useless now.
Signed-off-by: Paul Bolle
---
Tested with "git grep" only.
arch/arm/Kconfig | 1 -
arch/arm/mach-exynos/Kconfig | 1 -
2 files changed, 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0c990b7..2530799 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1172,7 +1172,6 @@ config PLAT_VERSATILE
config ARM_TIMER_SP804
bool
select CLKSRC_MMIO
- select HAVE_SCHED_CLOCK
source arch/arm/mm/Kconfig
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 068aeb5..acfdbcf 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -253,7 +253,6 @@ config MACH_UNIVERSAL_C210
select EXYNOS4_SETUP_USB_PHY
select EXYNOS_DEV_DMA
select EXYNOS_DEV_DRM
- select HAVE_SCHED_CLOCK
select S3C_DEV_HSMMC
select S3C_DEV_HSMMC2
select S3C_DEV_HSMMC3
--
1.7.11.7
--
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 00/23] RFC: exynos multiplatform support
On Tuesday 05 March 2013, Tomasz Figa wrote: > On Tuesday 05 of March 2013 19:19:02 Arnd Bergmann wrote: > > If none of these are needed for DT-based systems, we should probably > > build that code conditionally based on the CONFIG_EXYNOS_ATAGS symbol > > I introduced. > > Yes, none of them are needed for DT-based systems. Ah, good. I'll try to make more code conditional then. > > How are you planning to solve this? Do you want to have a combined > > driver that registers both a clocksource and a pwm? > > Let's start with a quick introduction to the s3c-pwm hardware. Each > channel has its own timer value, compare and reload value registers, so > they don't need any extra locking. However there are additional shared > configuration registers, containing things such as start and reload bits > for all channels, prescaler and main divisor values, etc. Those registers > needs synchronization. > > Now there are several possible approaches: > > 1) A brute force one - two separate drivers, based on the fact that the >clocksource driver will be used only on uniprocessor systems, so >a simple _irqsave when accessing a shared register in both will >guarantee correct synchronization. > > 2) Two separate drivers with some synchronized shared code accessing >registers (_start, _stop, _set_reload, _set_prescaler, _set_divisor, >etc.; all using a shared spinlock). > > 3) Single driver registering PWM channels, clocksource and clock event >device. This does not seem like a bad idea, since the whole code for >configuration of the PWM block would reside in one location and there >would be no redundancy. However there is a question where such driver >should be placed - drivers/clocksource, drivers/pwm, or maybe somewhere >else? > > Personally I wanted to go with first option, which would require least > amount of changes to existing code, at a cost of some code duplication > (but some PWM code is duplicated already). I would prefer option 3. That is also easier to implement with a straightforward DT binding that defines a single node with the clock registers. The location doesn't have an obvious answer, but I would probably put them into drivers/clocksource if the PWM maintainer agrees. Option 2 would probably come down to having a trivial MFD driver exposing a regmap. You can probably reuse drivers/mfd/syscon.c for this and make the node compatible with "syscon" to designate the clock registers as a system-wide resource, making the other device nodes register-less. 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
[PATCH] ARM: EXYNOS: change HAVE_SAMSUNG_KEYPAD to KEYBOARD_SAMSUNG
Commit 6b5ab4f442e32f248b6fad29aafd1d5153f4dbd3 ("ARM: EXYNOS: Add
Exynos4 device tree enabled board file") added
select HAVE_SAMSUNG_KEYPAD if INPUT_KEYBOARD
to the MACH_EXYNOS4_DT Kconfig entry. But there's no Kconfig symbol
HAVE_SAMSUNG_KEYPAD. Since this select statement depends on
INPUT_KEYBOARD this entry should select KEYBOARD_SAMSUNG instead.
Signed-off-by: Paul Bolle
---
0) Tested with "git grep" only.
1) Perhaps the fact that the symbol KEYBOARD_SAMSUNG enables a driver
called samsung-keypad caused confusion here. Anyhow, my choice for
KEYBOARD_SAMSUNG is only educated guesswork.
arch/arm/mach-exynos/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 6c2bdc3..068aeb5 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -403,7 +403,7 @@ config MACH_EXYNOS4_DT
depends on ARCH_EXYNOS4
select ARM_AMBA
select CPU_EXYNOS4210
- select HAVE_SAMSUNG_KEYPAD if INPUT_KEYBOARD
+ select KEYBOARD_SAMSUNG if INPUT_KEYBOARD
select PINCTRL
select PINCTRL_EXYNOS
select USE_OF
--
1.7.11.7
--
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 v6 5/5] ARM: dts: Add FIMD DT binding Documentation
Hi, On 4 March 2013 00:41, Sylwester Nawrocki wrote: > On 02/28/2013 10:42 AM, Vikas Sajjan wrote: >> >> Adds FIMD DT binding documentation both Samsung SoC and Board, with an >> example >> >> Signed-off-by: Vikas Sajjan >> --- >> .../devicetree/bindings/video/samsung-fimd.txt | 54 >> >> 1 file changed, 54 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/video/samsung-fimd.txt >> >> diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt >> b/Documentation/devicetree/bindings/video/samsung-fimd.txt >> new file mode 100644 >> index 000..8d201e7 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt >> @@ -0,0 +1,54 @@ >> +Device-Tree bindings for Samsung SoC display controller (FIMD) >> + >> +FIMD stands for Fully Interactive Mobile Display, is the Display >> Controller for >> +the Samsung series of SoCs which transfers the image data from a video >> buffer >> +located in the system memory to an external LCD interface. >> + >> +Required properties: >> +- compatible := value should be one of the following >> + "samsung,s3c2443-fimd"; /* for S3C24XX SoCs */ >> + "samsung,s3c6400-fimd"; /* for S3C64XX SoCs */ >> + "samsung,s5p6440-fimd"; /* for S5P64X0 SoCs */ >> + "samsung,s5pc100-fimd"; /* for S5PC100 SoC */ >> + "samsung,s5pv210-fimd"; /* for S5PV210 SoC */ >> + "samsung,exynos4210-fimd"; /* for Exynos4 SoCs */ >> + "samsung,exynos5250-fimd"; /* for Exynos5 SoCs */ >> + >> +- reg := physical base address of the fimd and length of memory mapped >> region > > > I think FIMD should be capitalized. > Right. > >> + >> +- interrupt-parent := reference to the interrupt combiner node with >> phandle > > > Perhaps this would have been more clear: > > - interrupt-parent : a phandle to the interrupt combiner node; > > ? OK. > > And could we just use a colon instead of ":=", to keep it more consistent > with other Samsung SoC DT bindings documentation ? > OK. > >> + >> +- interrupts := interrupt number from the combiner to the cpu. >> + We have 3 interrupts and the interrupt combiner order is >> + FIFO Level, VSYNC, and LCD_SYSTEM. >> + but since the driver expects VSYNC to be the first IRQ, >> + make sure to mention order as VSYNC, FIFO Level and >> LCD_SYSTEM >> + keeping VSYNC as first IRQ as shown below. >> + for example: interrupts =<11 1>,<11 0>,<11 2>; > > > I have a suggestion here. What about using reg-names property to make this > more explicit, e.g. > > - interrupts : should contain a list of all FIMD IP block interrupts: > FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier format depends > on the interrupt controller used; > > - interrupt-names : should contain the interrupt names: "fifo", "vsync", > "lcd_sys", in the order in which they were listed in the interrupts > property; > Good idea, but i am just wondering is it a good idea to modify the fimd driver ? > Or something similar to that. Then the drivers would need to be modified > to get interrupt resource by name, and not to rely on the VSYNC interrupt > be listed as the first one. > > >> + >> +- pinctrl := property defining the pinctrl configurations with a phandle >> + >> +- pinctrl-names := name of the pinctrl > > > Might be sufficient to just mention that the "default" state needs to be > specified in the fimd node, with reference to the pinctrl bindings > documentation, e.g. > > "The pinctrl bindings defined in ../../pinctrl/pinctrl-bindings.txt must be > used to define a pinctrl state named "default". > > See https://patchwork.kernel.org/patch/2082311. > OK. > >> +Optional Properties: >> +- samsung,power-domain := power domain property defined with a phandle > > > "a phandle to FIMD power domain node" ? OK -- Thanks and Regards Vikas Sajjan -- 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] iio: adc: exynos5_adc: fix compilation warnings
On Wed, Mar 06, 2013 at 09:44:47AM +0100, Lars-Peter Clausen wrote: > On 03/06/2013 05:11 AM, Naveen Krishna Chatradhi wrote: > > From: Naveen Krishna Ch > > > > Fixes the compilation warnings and potential NULL pointer > > dereferencing pointed out by "Dan Carpenter". > > > > I'd say that's a rather un-potential NULL pointer dereferencing, but if it > makes the static checkers happy, why not. Since the same match table is used > to > match the device, probe won't be called unless there is a match, so > of_match_node() will never return NULL in this case. > Actually the reason Smatch complains is because this was built with CONFIG_OF=n. Probably it should depend on that in the Kconfig file? The static checker warnings are a semi automatic thing and we only send the one email and then mark them as looked at. It's not worth silencing false positives unless it makes the code easier to audit. regards, dan carpenter -- 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 15/23] spi: s3c64xx: move to generic dmaengine API
Hi Arnd,
On Tue, Mar 5, 2013 at 11:12 PM, Arnd Bergmann wrote:
> The spi-s3c64xx uses a Samsung proprietary interface for
> talking to the DMA engine, which does not work with
> multiplatform kernels. Since the driver can also operate
> in PIO mode without any DMA, older platforms that do
> not support the DMA engine API will still work, although
> slower.
>
> The conversion was rather mechanical, since the samsung
> interface is just a shallow wrapper around the dmaengine
> interface.
>
> Signed-off-by: Arnd Bergmann
> ---
> arch/arm/plat-samsung/devs.c | 10 +++
> drivers/spi/spi-s3c64xx.c | 107
> ++
> include/linux/platform_data/spi-s3c64xx.h | 3 +
> 3 files changed, 62 insertions(+), 58 deletions(-)
>
> diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
> index 76209c9..58fb02a 100644
> --- a/arch/arm/plat-samsung/devs.c
> +++ b/arch/arm/plat-samsung/devs.c
> @@ -10,6 +10,7 @@
> * published by the Free Software Foundation.
> */
>
> +#include
> #include
> #include
> #include
> @@ -1551,6 +1552,9 @@ void __init s3c64xx_spi0_set_platdata(int
> (*cfg_gpio)(void), int src_clk_nr,
> pd.num_cs = num_cs;
> pd.src_clk_nr = src_clk_nr;
> pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi0_cfg_gpio;
> +#ifdef CONFIG_PL330_DMA
> + pd.filter = pl330_filter;
> +#endif
>
> s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi0);
> }
> @@ -1589,6 +1593,9 @@ void __init s3c64xx_spi1_set_platdata(int
> (*cfg_gpio)(void), int src_clk_nr,
> pd.num_cs = num_cs;
> pd.src_clk_nr = src_clk_nr;
> pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi1_cfg_gpio;
> +#ifdef CONFIG_PL330_DMA
> + pd.filter = pl330_filter;
> +#endif
>
> s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi1);
> }
> @@ -1627,6 +1634,9 @@ void __init s3c64xx_spi2_set_platdata(int
> (*cfg_gpio)(void), int src_clk_nr,
> pd.num_cs = num_cs;
> pd.src_clk_nr = src_clk_nr;
> pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi2_cfg_gpio;
> +#ifdef CONFIG_PL330_DMA
> + pd.filter = pl330_filter;
> +#endif
>
> s3c_set_platdata(&pd, sizeof(pd), &s3c64xx_device_spi2);
> }
> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
> index e862ab8..9be07a6 100644
> --- a/drivers/spi/spi-s3c64xx.c
> +++ b/drivers/spi/spi-s3c64xx.c
> @@ -22,8 +22,10 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -31,7 +33,6 @@
> #include
> #include
>
> -#include
> #include
>
> #define MAX_SPI_PORTS 3
> @@ -131,9 +132,9 @@
> #define TXBUSY(1<<3)
>
> struct s3c64xx_spi_dma_data {
> - unsignedch;
> + struct dma_chan *ch;
> enum dma_transfer_direction direction;
> - enum dma_ch dmach;
> + unsigned int request;
> };
>
> /**
> @@ -195,16 +196,11 @@ struct s3c64xx_spi_driver_data {
> unsignedcur_speed;
> struct s3c64xx_spi_dma_data rx_dma;
> struct s3c64xx_spi_dma_data tx_dma;
> - struct samsung_dma_ops *ops;
> struct s3c64xx_spi_port_config *port_conf;
> unsigned intport_id;
> unsigned long gpios[4];
> };
>
> -static struct s3c2410_dma_client s3c64xx_spi_dma_client = {
> - .name = "samsung-spi-dma",
> -};
> -
> static void flush_fifo(struct s3c64xx_spi_driver_data *sdd)
> {
> void __iomem *regs = sdd->regs;
> @@ -285,50 +281,42 @@ static void prepare_dma(struct s3c64xx_spi_dma_data
> *dma,
> unsigned len, dma_addr_t buf)
> {
> struct s3c64xx_spi_driver_data *sdd;
> - struct samsung_dma_prep info;
> - struct samsung_dma_config config;
> + struct dma_slave_config config;
> + struct scatterlist sg;
> + struct dma_async_tx_descriptor *desc;
>
> if (dma->direction == DMA_DEV_TO_MEM) {
> sdd = container_of((void *)dma,
> struct s3c64xx_spi_driver_data, rx_dma);
> - config.direction = sdd->rx_dma.direction;
> - config.fifo = sdd->sfr_start + S3C64XX_SPI_RX_DATA;
> - config.width = sdd->cur_bpw / 8;
> - sdd->ops->config(sdd->rx_dma.ch, &config);
> + config.direction = dma->direction;
> + config.src_addr = sdd->sfr_start + S3C64XX_SPI_RX_DATA;
> + config.src_addr_width = sdd->cur_bpw / 8;
> + config.src_maxburst = 1;
> + dmaengine_slave_config(dma->ch, &config);
> } else {
> sdd = container_of((void *)dma,
> struct s3c64xx_spi_driver_data, tx_dma);
> - config.direction = sdd->tx_dma.direction;
> - config.fifo = sdd->sfr_start + S3C64XX_SPI_TX_D
Re: [PATCH 18/23] ASoC: samsung: convert to dmaengine API
Hi Arnd,
On Tue, Mar 5, 2013 at 11:12 PM, Arnd Bergmann wrote:
> In order to build the exynos kernel with CONFIG_ARCH_MULTIPLATFORM,
> we must convert all users of the Samsung private DMA interface to
> the generic dmaengine API. This converts the sound/soc drivers,
> breaking the older s3c platforms in the process, since they do not
> support the dmaengine interface yet.
>
> This patch must not get mainlined until mach-s3c* is also converted,
> but can be used for testing in the meantime.
>
> Signed-off-by: Arnd Bergmann
> ---
> sound/soc/samsung/ac97.c| 15 --
> sound/soc/samsung/dma.c | 104
> +---
> sound/soc/samsung/dma.h | 4 +-
> sound/soc/samsung/i2s.c | 9 +---
> sound/soc/samsung/pcm.c | 13 -
> sound/soc/samsung/s3c2412-i2s.c | 10
> sound/soc/samsung/s3c24xx-i2s.c | 10
> sound/soc/samsung/spdif.c | 6 ---
> 8 files changed, 57 insertions(+), 114 deletions(-)
>
> diff --git a/sound/soc/samsung/ac97.c b/sound/soc/samsung/ac97.c
> index c76abdf..214f454 100644
> --- a/sound/soc/samsung/ac97.c
> +++ b/sound/soc/samsung/ac97.c
> @@ -39,30 +39,15 @@ struct s3c_ac97_info {
> };
> static struct s3c_ac97_info s3c_ac97;
>
> -static struct s3c2410_dma_client s3c_dma_client_out = {
> - .name = "AC97 PCMOut"
> -};
> -
> -static struct s3c2410_dma_client s3c_dma_client_in = {
> - .name = "AC97 PCMIn"
> -};
> -
> -static struct s3c2410_dma_client s3c_dma_client_micin = {
> - .name = "AC97 MicIn"
> -};
> -
> static struct s3c_dma_params s3c_ac97_pcm_out = {
> - .client = &s3c_dma_client_out,
> .dma_size = 4,
> };
>
> static struct s3c_dma_params s3c_ac97_pcm_in = {
> - .client = &s3c_dma_client_in,
> .dma_size = 4,
> };
>
> static struct s3c_dma_params s3c_ac97_mic_in = {
> - .client = &s3c_dma_client_micin,
> .dma_size = 4,
> };
>
> diff --git a/sound/soc/samsung/dma.c b/sound/soc/samsung/dma.c
> index 21b7926..67b8dcc 100644
> --- a/sound/soc/samsung/dma.c
> +++ b/sound/soc/samsung/dma.c
> @@ -16,14 +16,14 @@
>
> #include
> #include
> +#include
> #include
> +#include
>
> #include
> #include
>
> #include
> -#include
> -#include
>
> #include "dma.h"
>
> @@ -67,12 +67,16 @@ static void audio_buffdone(void *data);
> * place a dma buffer onto the queue for the dma system
> * to handle.
> */
> +
> static void dma_enqueue(struct snd_pcm_substream *substream)
> {
> struct runtime_data *prtd = substream->runtime->private_data;
> dma_addr_t pos = prtd->dma_pos;
> + unsigned long period = prtd->dma_period;
> unsigned int limit;
> - struct samsung_dma_prep dma_info;
> + enum dma_transfer_direction direction;
> + struct dma_chan *chan = prtd->params->ch;
> + struct dma_async_tx_descriptor *desc;
>
> pr_debug("Entered %s\n", __func__);
>
> @@ -81,29 +85,30 @@ static void dma_enqueue(struct snd_pcm_substream
> *substream)
> pr_debug("%s: loaded %d, limit %d\n",
> __func__, prtd->dma_loaded, limit);
>
> - dma_info.cap = (samsung_dma_has_circular() ? DMA_CYCLIC : DMA_SLAVE);
> - dma_info.direction =
> - (substream->stream == SNDRV_PCM_STREAM_PLAYBACK
> - ? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM);
> - dma_info.fp = audio_buffdone;
> - dma_info.fp_param = substream;
> - dma_info.period = prtd->dma_period;
> - dma_info.len = prtd->dma_period*limit;
> + direction = (substream->stream == SNDRV_PCM_STREAM_PLAYBACK
> +? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM);
>
> while (prtd->dma_loaded < limit) {
> pr_debug("dma_loaded: %d\n", prtd->dma_loaded);
>
> - if ((pos + dma_info.period) > prtd->dma_end) {
> - dma_info.period = prtd->dma_end - pos;
> + if ((pos + period) > prtd->dma_end) {
> + period = prtd->dma_end - pos;
> pr_debug("%s: corrected dma len %ld\n",
> - __func__, dma_info.period);
> + __func__, period);
> }
>
> - dma_info.buf = pos;
> - prtd->params->ops->prepare(prtd->params->ch, &dma_info);
> + desc = dmaengine_prep_dma_cyclic(chan, pos,
> +prtd->dma_period*limit, period, direction,
> + DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> +
> + if (desc) {
> + desc->callback = audio_buffdone;
> + desc->callback_param = substream;
> + dmaengine_submit(desc);
> + }
>
> prtd->dma_loaded++;
> - pos += prtd->dma_period;
> + pos += period;
> if (pos >= prtd->dma_end)
>
Re: [PATCH 1/2] ARM: EXYNOS: Add PCIe driver support
On Mon, Mar 04, 2013 at 10:22:28AM +, Jingoo Han wrote:
> Exynos5440 has two PCIe controllers which can be used as Root Complex.
> This driver supports the PCIe controllers as Root Complex mode.
>
> Signed-off-by: Surendranath Gurivireddy Balla
> Signed-off-by: Siva Reddy Kallam
> Signed-off-by: Jingoo Han
> ---
> .../devicetree/bindings/pci/exynos-pcie.txt| 58 ++
> arch/arm/Kconfig |2 +
> arch/arm/mach-exynos/Kconfig |8 +
> arch/arm/mach-exynos/Makefile |2 +
> arch/arm/mach-exynos/include/mach/pcie.h | 146 +++
> arch/arm/mach-exynos/pcie.c| 1009
>
> 6 files changed, 1225 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pci/exynos-pcie.txt
> create mode 100644 arch/arm/mach-exynos/include/mach/pcie.h
> create mode 100644 arch/arm/mach-exynos/pcie.c
>
> diff --git a/Documentation/devicetree/bindings/pci/exynos-pcie.txt
> b/Documentation/devicetree/bindings/pci/exynos-pcie.txt
> new file mode 100644
> index 000..4fe05b5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/exynos-pcie.txt
> @@ -0,0 +1,58 @@
> +* Samsung Exynos PCIe interface
> +
> +Required properties:
> +-compatible: should be "samsung,pcie-host"
> +-reg: base addresses and lengths of the pcie conteroller,
> + additional register for the pcie controller,
> + the phy controller,
> + additional register for the phy controller.
> +- interrupts: interrupt values for level interrupt,
> + pulse interrupt, special interrupt.
> +- pcie-host,io_size: memory size for IO
> +- pcie-host,cfg0_size: memory size for CFG0
> +- pcie-host,cfg1_size: memory size for CFG1
> +- pcie-host,mem_size: memory size for MEM
> +- pcie-host,in_mem_size: memory size for Inbound MEM
> +- reset-gpio: gpio pin number of power good signal
> +
> +Example:
> +
> +SoC specific DT Entry:
> +
> + pcie0@4000 {
> + compatible = "samsung,pcie-host";
> + reg = <0x4000 0x4000
> + 0x29 0x1000
> + 0x27 0x1000
> + 0x271000 0x40>;
> + interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
> + pcie-host,io_size = <0x4000>;
> + pcie-host,cfg0_size = <0x10>;
> + pcie-host,cfg1_size = <0x10>;
> + pcie-host,mem_size = <0x1000>;
> + pcie-host,in_mem_size = <0x800>;
> + };
> +
It's quite common for information such as mem_size and io_size to be represented
with the defacto binding ranges - see
http://devicetree.org/Device_Tree_Usage#PCI_Address_Translation. Thomas
Petazzoni
and Thierry Reding have recent patch sets that use this representation.
The ranges property is used across many architectures of the kernel, however
each architecture has its own way of parsing this binding. There isn't an
accepted version for ARM yet but efforts are underway to add one that doesn't
duplicate code.
It would probably make sense for all these new PCIe host drivers to be
consistent where possible.
Andrew Murray
--
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] iio: adc: exynos5_adc: fix compilation warnings
On 03/06/2013 05:11 AM, Naveen Krishna Chatradhi wrote:
> From: Naveen Krishna Ch
>
> Fixes the compilation warnings and potential NULL pointer
> dereferencing pointed out by "Dan Carpenter".
>
I'd say that's a rather un-potential NULL pointer dereferencing, but if it
makes the static checkers happy, why not. Since the same match table is used to
match the device, probe won't be called unless there is a match, so
of_match_node() will never return NULL in this case.
> Signed-off-by: Naveen Krishna Ch
> ---
> drivers/iio/adc/exynos_adc.c | 24 +---
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
> index ed6fdd7..67d07aa 100644
> --- a/drivers/iio/adc/exynos_adc.c
> +++ b/drivers/iio/adc/exynos_adc.c
> @@ -92,7 +92,7 @@ struct exynos_adc {
> struct completion completion;
>
> u32 value;
> - unsigned intversion;
> + unsigned intversion;
> };
>
> static const struct of_device_id exynos_adc_match[] = {
> @@ -102,12 +102,15 @@ static const struct of_device_id exynos_adc_match[] = {
> };
> MODULE_DEVICE_TABLE(of, exynos_adc_match);
>
> -static inline unsigned int exynos_adc_get_version(struct platform_device
> *pdev)
> +static inline int exynos_adc_get_version(struct platform_device *pdev)
> {
> const struct of_device_id *match;
>
> match = of_match_node(exynos_adc_match, pdev->dev.of_node);
> - return (unsigned int)match->data;
> + if (!match)
> + return -ENODEV;
> +
> + return (int)match->data;
> }
>
> static int exynos_read_raw(struct iio_dev *indio_dev,
> @@ -117,7 +120,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
> long mask)
> {
> struct exynos_adc *info = iio_priv(indio_dev);
> - unsigned long timeout;
> + int timeout;
> u32 con1, con2;
>
> if (mask != IIO_CHAN_INFO_RAW)
> @@ -255,7 +258,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
> struct iio_dev *indio_dev = NULL;
> struct resource *mem;
> int ret = -ENODEV;
> - int irq;
> + int irq, version;
>
> if (!np)
> return ret;
> @@ -268,6 +271,15 @@ static int exynos_adc_probe(struct platform_device *pdev)
>
> info = iio_priv(indio_dev);
>
> + version = exynos_adc_get_version(pdev);
> + if (version < 0) {
> + dev_err(&pdev->dev, "no matching of_node, err = %d\n", version);
> + ret = version;
> + goto err_iio;
> + }
> +
> + info->version = version;
> +
> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>
> info->regs = devm_request_and_ioremap(&pdev->dev, mem);
> @@ -311,8 +323,6 @@ static int exynos_adc_probe(struct platform_device *pdev)
> goto err_irq;
> }
>
> - info->version = exynos_adc_get_version(pdev);
> -
> platform_set_drvdata(pdev, indio_dev);
>
> indio_dev->name = dev_name(&pdev->dev);
--
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
