Re: [PATCH V3 2/3] phy: Add driver for Exynos DP PHY
On Tuesday, July 02, 2013 4:48 AM, Sylwester Nawrocki wrote:
> On 07/01/2013 07:24 AM, Jingoo Han wrote:
> > Add a PHY provider driver for the Samsung Exynos SoC DP PHY.
> >
> > Signed-off-by: Jingoo Han
> > Cc: Sylwester Nawrocki
> > Acked-by: Felipe Balbi
> > ---
> > .../devicetree/bindings/phy/samsung-phy.txt|8 ++
> > drivers/phy/Kconfig|5 +
> > drivers/phy/Makefile |1 +
> > drivers/phy/phy-exynos-dp-video.c | 118
> >
> > 4 files changed, 132 insertions(+)
> > create mode 100644 drivers/phy/phy-exynos-dp-video.c
> >
> > diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> > index 5ff208c..3fb656a 100644
> > --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> > +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> > @@ -12,3 +12,11 @@ the PHY specifier identifies the PHY and its meaning is
> > as follows:
> > 1 - MIPI DSIM 0,
> > 2 - MIPI CSIS 1,
> > 3 - MIPI DSIM 1.
> > +
> > +Samsung EXYNOS SoC series DP PHY
>
> I would make it "Samsung EXYNOS SoC series Display Port PHY"
OK.
>
> > +-
> > +
> > +Required properties:
> > +- compatible : should be "samsung,exynos5250-dp-video-phy";
> > +- reg : offset and length of the DP PHY register set;
> > +- #phy-cells : from the generic phy bindings, must be 0;
>
> s/phy/PHY ?
OK.
>
> > \ No newline at end of file
>
> Missing new line character.
OK.
>
> > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> > index 6f446d0..760f55a 100644
> > --- a/drivers/phy/Kconfig
> > +++ b/drivers/phy/Kconfig
> > @@ -19,4 +19,9 @@ config PHY_EXYNOS_MIPI_VIDEO
> > help
> > Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung
> > S5P and EXYNOS SoCs.
> > +
> > +config PHY_EXYNOS_DP_VIDEO
> > + tristate "EXYNOS SoC series DP PHY driver"
>
> "EXYNOS SoC series Display Port PHY driver" ?
>
> > + help
> > + Support for DP PHY found on Samsung EXYNOS SoCs.
>
> s/DP/Display Port ?
OK.
>
> > endif
> > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> > index 71d8841..0fd1340 100644
> > --- a/drivers/phy/Makefile
> > +++ b/drivers/phy/Makefile
> > @@ -4,3 +4,4 @@
> >
> > obj-$(CONFIG_GENERIC_PHY) += phy-core.o
> > obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
> > +obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
> > diff --git a/drivers/phy/phy-exynos-dp-video.c
> > b/drivers/phy/phy-exynos-dp-video.c
> > new file mode 100644
> > index 000..75e1d11
> > --- /dev/null
> > +++ b/drivers/phy/phy-exynos-dp-video.c
> > @@ -0,0 +1,118 @@
> > +/*
> > + * Samsung EXYNOS SoC series DP PHY driver
>
> s/DP/Display Port ?
OK.
>
> > + *
> > + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> > + * Author: Jingoo Han
> > + *
> > + * 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.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/* DPTX_PHY_CONTROL register */
> > +#define EXYNOS_DPTX_PHY_ENABLE (1<< 0)
> > +
> > +struct exynos_dp_video_phy {
> > + void __iomem *regs;
> > +};
> > +
> > +static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int
> > on)
> > +{
> > + void __iomem *addr;
>
> How about just dropping this local variable ?
OK.
I will drop this local variable.
>
> > + u32 reg;
> > +
> > + addr = state->regs;
> > +
> > + reg = readl(addr);
> > + if (on)
> > + reg |= EXYNOS_DPTX_PHY_ENABLE;
> > + else
> > + reg&= ~EXYNOS_DPTX_PHY_ENABLE;
> > + writel(reg, addr);
> > +
> > + return 0;
> > +}
> > +
> > +static int exynos_dp_video_phy_power_on(struct phy *phy)
> > +{
> > + struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
> > +
> > + return __set_phy_state(state, 1);
> > +}
> > +
> > +static int exynos_dp_video_phy_power_off(struct phy *phy)
> > +{
> > + struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
> > +
> > + return __set_phy_state(state, 0);
> > +}
> > +
> > +static struct phy_ops exynos_dp_video_phy_ops = {
> > + .power_on = exynos_dp_video_phy_power_on,
> > + .power_off = exynos_dp_video_phy_power_off,
> > + .owner = THIS_MODULE,
> > +};
> > +
> > +static int exynos_dp_video_phy_probe(struct platform_device *pdev)
> > +{
> > + struct exynos_dp_video_phy *state;
> > + struct device *dev =&pdev->dev;
> > + struct resource *res;
> > + struct phy_provider *phy_provider;
> > + struct phy *phy;
> > +
> > + state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
> > + if (!state)
> > + return -ENOMEM;
> > +
> > + res = platform_get_res
Re: [PATCH RFC 2/3] dt:net:stmmac: Add support to dwmac version 3.610 and 3.710
Thanks Peppe for the comments,
On 01/07/13 18:20, Giuseppe CAVALLARO wrote:
> On 7/1/2013 1:43 PM, Srinivas KANDAGATLA wrote:
>> From: Srinivas Kandagatla
>>
>> +
>> +plat->bus_id = of_alias_get_id(np, "ethernet");
>> +if (plat->bus_id < 0)
>> +plat->bus_id = 0;
>> +
>> +of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr);
>> +
>> plat->mdio_bus_data = devm_kzalloc(&pdev->dev,
>> sizeof(struct stmmac_mdio_bus_data),
>> GFP_KERNEL);
>> @@ -51,11 +60,25 @@ static int stmmac_probe_config_dt(struct
>> platform_device *pdev,
>>*/
>> if (of_device_is_compatible(np, "st,spear600-gmac") ||
>> of_device_is_compatible(np, "snps,dwmac-3.70a") ||
>> +of_device_is_compatible(np, "snps,dwmac-3.610") ||
I forgot to add "snps,dwmac-3.710" to this list, I will do it in V2 patch.
>> of_device_is_compatible(np, "snps,dwmac")) {
>> plat->has_gmac = 1;
>> plat->pmt = 1;
>> }
>>
>> +if (of_device_is_compatible(np, "snps,dwmac-3.610") ||
>> +of_device_is_compatible(np, "snps,dwmac-3.710")) {
>> +plat->enh_desc = 1;
>> +plat->bugged_jumbo = 1;
>> +plat->force_sf_dma_mode = 1;
>> +}
>
> I think some these shouldn't be forced here. Maybe plat->enh_desc could
> be set because for new syn mac cores.
>
> Also pmt could not be forced because it is an extra module so it could
> happen that a new chip has no PMT block.
I agree with you, But the new chips should/will have different version
numbers, so having the version number in the compatible string should
make it possible for cores without PMT module to not set pmt or any
other properties.
Are you happy with the setting pmt based on compatible string or do you
think passing pmt as another property to device tree makes more sense?
Thanks,
srini
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 4/4] ARM: dts: AM33XX: update rtc node compatibility
On Tue, Jul 02, 2013 at 11:42:49, Nori, Sekhar wrote:
> Changing to Benoit's gmail id since he apparently wont access TI mail
> anymore.
>
> On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
> > Since AM33xx RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
> >
> > Update the rtc compatible property to "ti,am3352-rtc" to enable handling
> > of this feature inside rtc-omap driver.
> >
> > Signed-off-by: Hebbar Gururaja
> > Cc: Tony Lindgren
> > Cc: Sekhar Nori
> > Cc: Kevin Hilman
> > Cc: b-cous...@ti.com
> > ---
> > :100644 100644 77aa1b0... dde180a... M arch/arm/boot/dts/am33xx.dtsi
> > arch/arm/boot/dts/am33xx.dtsi |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> > index 77aa1b0..dde180a 100644
> > --- a/arch/arm/boot/dts/am33xx.dtsi
> > +++ b/arch/arm/boot/dts/am33xx.dtsi
> > @@ -297,7 +297,7 @@
> > };
> >
> > rtc@44e3e000 {
> > - compatible = "ti,da830-rtc";
> > + compatible = "ti,am3352-rtc";
>
> compatible is a list so you can instead do:
>
> compatible = "ti,am3352-rtc", "ti,da830-rtc";
I believe the order is not important here. I mean, below is also fine. Right?
compatible = "ti,da830-rtc", "ti,am3352-rtc";
>
> That way the dts works irrespective of driver updates. When driver
> supports enhanced features of hardware, they are available to the user
> else the basic functionality still works.
>
> Thanks,
> Sekhar
>
Regards,
Gururaja
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
On 7/2/2013 11:41 AM, Hebbar, Gururaja wrote:
> On Tue, Jul 02, 2013 at 11:39:28, Nori, Sekhar wrote:
>> On 7/2/2013 11:34 AM, Hebbar, Gururaja wrote:
>>> On Tue, Jul 02, 2013 at 11:32:34, Nori, Sekhar wrote:
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
> On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
> is available to enable Alarm Wakeup feature. This register needs to be
> properly handled for the rtcwake to work properly.
>
> Platforms using such IP should set "ti,am3352-rtc" in rtc device dt
> compatibility node.
>
> Signed-off-by: Hebbar Gururaja
> Cc: Grant Likely
> Cc: Rob Herring
> Cc: Rob Landley
> Cc: Sekhar Nori
> Cc: Kevin Hilman
> Cc: Alessandro Zummo
> Cc: rtc-li...@googlegroups.com
> Cc: devicetree-discuss@lists.ozlabs.org
> Cc: linux-...@vger.kernel.org
> ---
[...]
> -#define OMAP_RTC_DATA_DA830_IDX 1
> +#define OMAP_RTC_DATA_DA830_IDX 1
> +#define OMAP_RTC_DATA_AM335X_IDX2
>
> static struct platform_device_id omap_rtc_devtype[] = {
> {
> @@ -309,6 +321,9 @@ static struct platform_device_id omap_rtc_devtype[] =
> {
> }, {
> .name = "da830-rtc",
> .driver_data = OMAP_RTC_HAS_KICKER,
> + }, {
> + .name = "am335x-rtc",
may be use am3352-rtc here just to keep the platform device name and of
compatible in sync.
>>>
>>> Correct. I will update the same in v2.
>>>
> + .driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
> },
> {},
It is better to use the index defined above in the static initialization
so they remain in sync.
>>>
>>> Sorry. I didn’t get this.
>>>
>>
>> See example below I provided. If its still not clear, let me know what
>> is not clear.
>>
...
[OMAP_RTC_DATA_DA830_IDX] = {
.name = "da830-rtc",
.driver_data = OMAP_RTC_HAS_KICKER,
},
>
> Thanks for the clarification. In this case will it ok if I update the previous
> member also.
You dont really reference [0] in omap_rtc_of_match[] so even if you
leave it as-is, that's fine with me. I am mostly concerned with the
index definitions and initialization order being out of sync and that's
really not an issue with [0].
Thanks,
Sekhar
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 4/4] ARM: dts: AM33XX: update rtc node compatibility
On Tue, Jul 02, 2013 at 11:42:49, Nori, Sekhar wrote:
> Changing to Benoit's gmail id since he apparently wont access TI mail
> anymore.
>
> On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
> > Since AM33xx RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
> >
> > Update the rtc compatible property to "ti,am3352-rtc" to enable handling
> > of this feature inside rtc-omap driver.
> >
> > Signed-off-by: Hebbar Gururaja
> > Cc: Tony Lindgren
> > Cc: Sekhar Nori
> > Cc: Kevin Hilman
> > Cc: b-cous...@ti.com
> > ---
> > :100644 100644 77aa1b0... dde180a... M arch/arm/boot/dts/am33xx.dtsi
> > arch/arm/boot/dts/am33xx.dtsi |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> > index 77aa1b0..dde180a 100644
> > --- a/arch/arm/boot/dts/am33xx.dtsi
> > +++ b/arch/arm/boot/dts/am33xx.dtsi
> > @@ -297,7 +297,7 @@
> > };
> >
> > rtc@44e3e000 {
> > - compatible = "ti,da830-rtc";
> > + compatible = "ti,am3352-rtc";
>
> compatible is a list so you can instead do:
>
> compatible = "ti,am3352-rtc", "ti,da830-rtc";
>
> That way the dts works irrespective of driver updates. When driver
> supports enhanced features of hardware, they are available to the user
> else the basic functionality still works.
Ok. I will update the same now in v2.
>
> Thanks,
> Sekhar
>
Regards,
Gururaja
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 4/4] ARM: dts: AM33XX: update rtc node compatibility
Changing to Benoit's gmail id since he apparently wont access TI mail
anymore.
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
> Since AM33xx RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
>
> Update the rtc compatible property to "ti,am3352-rtc" to enable handling
> of this feature inside rtc-omap driver.
>
> Signed-off-by: Hebbar Gururaja
> Cc: Tony Lindgren
> Cc: Sekhar Nori
> Cc: Kevin Hilman
> Cc: b-cous...@ti.com
> ---
> :100644 100644 77aa1b0... dde180a... March/arm/boot/dts/am33xx.dtsi
> arch/arm/boot/dts/am33xx.dtsi |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 77aa1b0..dde180a 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -297,7 +297,7 @@
> };
>
> rtc@44e3e000 {
> - compatible = "ti,da830-rtc";
> + compatible = "ti,am3352-rtc";
compatible is a list so you can instead do:
compatible = "ti,am3352-rtc", "ti,da830-rtc";
That way the dts works irrespective of driver updates. When driver
supports enhanced features of hardware, they are available to the user
else the basic functionality still works.
Thanks,
Sekhar
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
On Tue, Jul 02, 2013 at 11:39:28, Nori, Sekhar wrote:
> On 7/2/2013 11:34 AM, Hebbar, Gururaja wrote:
> > On Tue, Jul 02, 2013 at 11:32:34, Nori, Sekhar wrote:
> >> On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
> >>> On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
> >>> is available to enable Alarm Wakeup feature. This register needs to be
> >>> properly handled for the rtcwake to work properly.
> >>>
> >>> Platforms using such IP should set "ti,am3352-rtc" in rtc device dt
> >>> compatibility node.
> >>>
> >>> Signed-off-by: Hebbar Gururaja
> >>> Cc: Grant Likely
> >>> Cc: Rob Herring
> >>> Cc: Rob Landley
> >>> Cc: Sekhar Nori
> >>> Cc: Kevin Hilman
> >>> Cc: Alessandro Zummo
> >>> Cc: rtc-li...@googlegroups.com
> >>> Cc: devicetree-discuss@lists.ozlabs.org
> >>> Cc: linux-...@vger.kernel.org
> >>> ---
> >>
> >> [...]
> >>
> >>> -#define OMAP_RTC_DATA_DA830_IDX 1
> >>> +#define OMAP_RTC_DATA_DA830_IDX 1
> >>> +#define OMAP_RTC_DATA_AM335X_IDX2
> >>>
> >>> static struct platform_device_id omap_rtc_devtype[] = {
> >>> {
> >>> @@ -309,6 +321,9 @@ static struct platform_device_id omap_rtc_devtype[] =
> >>> {
> >>> }, {
> >>> .name = "da830-rtc",
> >>> .driver_data = OMAP_RTC_HAS_KICKER,
> >>> + }, {
> >>> + .name = "am335x-rtc",
> >>
> >> may be use am3352-rtc here just to keep the platform device name and of
> >> compatible in sync.
> >
> > Correct. I will update the same in v2.
> >
> >>
> >>> + .driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
> >>> },
> >>> {},
> >>
> >> It is better to use the index defined above in the static initialization
> >> so they remain in sync.
> >
> > Sorry. I didn’t get this.
> >
>
> See example below I provided. If its still not clear, let me know what
> is not clear.
>
> >>...
> >>[OMAP_RTC_DATA_DA830_IDX] = {
> >>.name = "da830-rtc",
> >>.driver_data = OMAP_RTC_HAS_KICKER,
> >>},
Thanks for the clarification. In this case will it ok if I update the previous
member also.
>
> Thanks,
> Sekhar
>
Regards,
Gururaja
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
On 7/2/2013 11:34 AM, Hebbar, Gururaja wrote:
> On Tue, Jul 02, 2013 at 11:32:34, Nori, Sekhar wrote:
>> On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
>>> On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
>>> is available to enable Alarm Wakeup feature. This register needs to be
>>> properly handled for the rtcwake to work properly.
>>>
>>> Platforms using such IP should set "ti,am3352-rtc" in rtc device dt
>>> compatibility node.
>>>
>>> Signed-off-by: Hebbar Gururaja
>>> Cc: Grant Likely
>>> Cc: Rob Herring
>>> Cc: Rob Landley
>>> Cc: Sekhar Nori
>>> Cc: Kevin Hilman
>>> Cc: Alessandro Zummo
>>> Cc: rtc-li...@googlegroups.com
>>> Cc: devicetree-discuss@lists.ozlabs.org
>>> Cc: linux-...@vger.kernel.org
>>> ---
>>
>> [...]
>>
>>> -#defineOMAP_RTC_DATA_DA830_IDX 1
>>> +#defineOMAP_RTC_DATA_DA830_IDX 1
>>> +#defineOMAP_RTC_DATA_AM335X_IDX2
>>>
>>> static struct platform_device_id omap_rtc_devtype[] = {
>>> {
>>> @@ -309,6 +321,9 @@ static struct platform_device_id omap_rtc_devtype[] = {
>>> }, {
>>> .name = "da830-rtc",
>>> .driver_data = OMAP_RTC_HAS_KICKER,
>>> + }, {
>>> + .name = "am335x-rtc",
>>
>> may be use am3352-rtc here just to keep the platform device name and of
>> compatible in sync.
>
> Correct. I will update the same in v2.
>
>>
>>> + .driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
>>> },
>>> {},
>>
>> It is better to use the index defined above in the static initialization
>> so they remain in sync.
>
> Sorry. I didn’t get this.
>
See example below I provided. If its still not clear, let me know what
is not clear.
>> ...
>> [OMAP_RTC_DATA_DA830_IDX] = {
>> .name = "da830-rtc",
>> .driver_data = OMAP_RTC_HAS_KICKER,
>> },
Thanks,
Sekhar
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] leds: Add device tree binding for pca9633
* Bryan Wu [130701 12:12]: > On Thu, Jun 27, 2013 at 7:24 AM, Tony Lindgren wrote: > > * Tony Lindgren [130627 00:28]: > >> * Bryan Wu [130626 16:53]: > >> > On Wed, Jun 26, 2013 at 7:17 AM, Tony Lindgren wrote: > >> > > @@ -22,6 +22,7 @@ > >> > > #include > >> > > #include > >> > > #include > >> > > +#include > >> > > #include > >> > > > >> > > /* LED select registers determine the source that drives LED outputs > >> > > */ > >> > > @@ -93,6 +94,61 @@ static void pca9633_led_set(struct led_classdev > >> > > *led_cdev, > >> > > schedule_work(&pca9633->work); > >> > > } > >> > > > >> > > +#ifdef CONFIG_OF > >> > > >> > Shall we use "#if IS_ENABLED(CONFIG_OF)", as Grant pointed out recently. > >> > >> Thanks will do, I'll also add the push-pull vs totem pole binding > >> as that can be quite crucial for some hardware configurations. > > > > Here's the updated patch. > > > > Regards, > > > > Tony > > > > Thanks, I merged it into my -devel branch. And it targets for 3.12 > merge window, since 3.11 merge window opened right now. OK thanks! Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
On Tue, Jul 02, 2013 at 11:32:34, Nori, Sekhar wrote:
> On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
> > On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
> > is available to enable Alarm Wakeup feature. This register needs to be
> > properly handled for the rtcwake to work properly.
> >
> > Platforms using such IP should set "ti,am3352-rtc" in rtc device dt
> > compatibility node.
> >
> > Signed-off-by: Hebbar Gururaja
> > Cc: Grant Likely
> > Cc: Rob Herring
> > Cc: Rob Landley
> > Cc: Sekhar Nori
> > Cc: Kevin Hilman
> > Cc: Alessandro Zummo
> > Cc: rtc-li...@googlegroups.com
> > Cc: devicetree-discuss@lists.ozlabs.org
> > Cc: linux-...@vger.kernel.org
> > ---
>
> [...]
>
> > -#defineOMAP_RTC_DATA_DA830_IDX 1
> > +#defineOMAP_RTC_DATA_DA830_IDX 1
> > +#defineOMAP_RTC_DATA_AM335X_IDX2
> >
> > static struct platform_device_id omap_rtc_devtype[] = {
> > {
> > @@ -309,6 +321,9 @@ static struct platform_device_id omap_rtc_devtype[] = {
> > }, {
> > .name = "da830-rtc",
> > .driver_data = OMAP_RTC_HAS_KICKER,
> > + }, {
> > + .name = "am335x-rtc",
>
> may be use am3352-rtc here just to keep the platform device name and of
> compatible in sync.
Correct. I will update the same in v2.
>
> > + .driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
> > },
> > {},
>
> It is better to use the index defined above in the static initialization
> so they remain in sync.
Sorry. I didn’t get this.
>
> ...
> [OMAP_RTC_DATA_DA830_IDX] = {
> .name = "da830-rtc",
> .driver_data = OMAP_RTC_HAS_KICKER,
> },
> ...
>
> > };
> > @@ -318,6 +333,9 @@ static const struct of_device_id omap_rtc_of_match[] = {
> > { .compatible = "ti,da830-rtc",
> > .data = &omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
> > },
> > + { .compatible = "ti,am3352-rtc",
> > + .data = &omap_rtc_devtype[OMAP_RTC_DATA_AM335X_IDX],
> > + },
> > {},
> > };
> > MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
>
> Apart from these minor issues, the patch looks good to me.
>
> Acked-by: Sekhar Nori
>
> Thanks,
> Sekhar
>
Regards,
Gururaja
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
> On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
> is available to enable Alarm Wakeup feature. This register needs to be
> properly handled for the rtcwake to work properly.
>
> Platforms using such IP should set "ti,am3352-rtc" in rtc device dt
> compatibility node.
>
> Signed-off-by: Hebbar Gururaja
> Cc: Grant Likely
> Cc: Rob Herring
> Cc: Rob Landley
> Cc: Sekhar Nori
> Cc: Kevin Hilman
> Cc: Alessandro Zummo
> Cc: rtc-li...@googlegroups.com
> Cc: devicetree-discuss@lists.ozlabs.org
> Cc: linux-...@vger.kernel.org
> ---
[...]
> -#define OMAP_RTC_DATA_DA830_IDX 1
> +#define OMAP_RTC_DATA_DA830_IDX 1
> +#define OMAP_RTC_DATA_AM335X_IDX2
>
> static struct platform_device_id omap_rtc_devtype[] = {
> {
> @@ -309,6 +321,9 @@ static struct platform_device_id omap_rtc_devtype[] = {
> }, {
> .name = "da830-rtc",
> .driver_data = OMAP_RTC_HAS_KICKER,
> + }, {
> + .name = "am335x-rtc",
may be use am3352-rtc here just to keep the platform device name and of
compatible in sync.
> + .driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
> },
> {},
It is better to use the index defined above in the static initialization
so they remain in sync.
...
[OMAP_RTC_DATA_DA830_IDX] = {
.name = "da830-rtc",
.driver_data = OMAP_RTC_HAS_KICKER,
},
...
> };
> @@ -318,6 +333,9 @@ static const struct of_device_id omap_rtc_of_match[] = {
> { .compatible = "ti,da830-rtc",
> .data = &omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
> },
> + { .compatible = "ti,am3352-rtc",
> + .data = &omap_rtc_devtype[OMAP_RTC_DATA_AM335X_IDX],
> + },
> {},
> };
> MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
Apart from these minor issues, the patch looks good to me.
Acked-by: Sekhar Nori
Thanks,
Sekhar
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 2/4] davinci: da8xx/omap-l1: Remove hard coding of rtc device wakeup
On Tue, Jul 02, 2013 at 11:10:14, Nori, Sekhar wrote: > > On 6/28/2013 3:05 PM, Hebbar Gururaja wrote: > > Since now rtc-omap driver itself calls deice_init_wakeup(dev, true), > > duplicate call from the rtc device registration can be removed. > > > > This is basically a partial revert of the prev commit > > > > commit 75c99bb0006ee065b4e2995078d779418b0fab54 > > Author: Sekhar Nori > > > > davinci: da8xx/omap-l1: mark RTC as a wakeup source > > > > Signed-off-by: Hebbar Gururaja > > Cc: Sekhar Nori > > Cc: Kevin Hilman > > Cc: Russell King > > Subject line should be prefixed with ARM: keeping with arch/arm > convention. Otherwise looks good. Will fix it in v2. > > Acked-by: Sekhar Nori Thanks for the review. > > Thanks, > Sekhar > Regards, Gururaja ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/4] davinci: da8xx/omap-l1: Remove hard coding of rtc device wakeup
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote: > Since now rtc-omap driver itself calls deice_init_wakeup(dev, true), > duplicate call from the rtc device registration can be removed. > > This is basically a partial revert of the prev commit > > commit 75c99bb0006ee065b4e2995078d779418b0fab54 > Author: Sekhar Nori > > davinci: da8xx/omap-l1: mark RTC as a wakeup source > > Signed-off-by: Hebbar Gururaja > Cc: Sekhar Nori > Cc: Kevin Hilman > Cc: Russell King Subject line should be prefixed with ARM: keeping with arch/arm convention. Otherwise looks good. Acked-by: Sekhar Nori Thanks, Sekhar ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 2/4] davinci: da8xx/omap-l1: Remove hard coding of rtc device wakeup
On Tue, Jul 02, 2013 at 05:37:43, Kevin Hilman wrote:
> Hebbar Gururaja writes:
>
> > Since now rtc-omap driver itself calls deice_init_wakeup(dev, true),
> > duplicate call from the rtc device registration can be removed.
> >
> > This is basically a partial revert of the prev commit
> >
> > commit 75c99bb0006ee065b4e2995078d779418b0fab54
> > Author: Sekhar Nori
> >
> > davinci: da8xx/omap-l1: mark RTC as a wakeup source
> >
> > Signed-off-by: Hebbar Gururaja
> > Cc: Sekhar Nori
> > Cc: Kevin Hilman
> > Cc: Russell King
> >
> > ---
> > :100644 100644 bf57252... 85a900c... M
> > arch/arm/mach-davinci/devices-da8xx.c
> > arch/arm/mach-davinci/devices-da8xx.c |9 +
> > 1 file changed, 1 insertion(+), 8 deletions(-)
> >
> > diff --git a/arch/arm/mach-davinci/devices-da8xx.c
> > b/arch/arm/mach-davinci/devices-da8xx.c
> > index bf57252..85a900c 100644
> > --- a/arch/arm/mach-davinci/devices-da8xx.c
> > +++ b/arch/arm/mach-davinci/devices-da8xx.c
> > @@ -827,14 +827,7 @@ static struct platform_device da8xx_rtc_device = {
> >
> > int da8xx_register_rtc(void)
> > {
> > - int ret;
> > -
> > - ret = platform_device_register(&da8xx_rtc_device);
> > - if (!ret)
> > - /* Atleast on DA850, RTC is a wakeup source */
> > - device_init_wakeup(&da8xx_rtc_device.dev, true);
> > -
> > - return ret;
> > + return platform_device_register(&da8xx_rtc_device);
>
> nit: extra space between 'return' and 'platform_'
Thanks for the review. V2 will soon follow.
>
> > }
> >
> > static void __iomem *da8xx_ddr2_ctlr_base;
>
> Otherwise,
>
> Acked-by: Kevin Hilman
>
>
Regards,
Gururaja
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
On Tue, Jul 02, 2013 at 05:45:01, Kevin Hilman wrote: > Hebbar Gururaja writes: > > > On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN) > > is available to enable Alarm Wakeup feature. This register needs to be > > properly handled for the rtcwake to work properly. > > > > Platforms using such IP should set "ti,am3352-rtc" in rtc device dt > > compatibility node. > > > > Signed-off-by: Hebbar Gururaja > > Cc: Grant Likely > > Cc: Rob Herring > > Cc: Rob Landley > > Cc: Sekhar Nori > > Cc: Kevin Hilman > > Cc: Alessandro Zummo > > Cc: rtc-li...@googlegroups.com > > Cc: devicetree-discuss@lists.ozlabs.org > > Cc: linux-...@vger.kernel.org > > Acked-by: Kevin Hilman > > ...with a minor nit below... > > > --- > > :100644 100644 b47aa41... 5a0f02d... M > > Documentation/devicetree/bindings/rtc/rtc-omap.txt > > :100644 100644 761919d... 666b0c2... M drivers/rtc/rtc-omap.c > > Documentation/devicetree/bindings/rtc/rtc-omap.txt |6 ++- > > drivers/rtc/rtc-omap.c | 56 > > +--- > > 2 files changed, 54 insertions(+), 8 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt > > b/Documentation/devicetree/bindings/rtc/rtc-omap.txt > > index b47aa41..5a0f02d 100644 > > --- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt > > +++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt > > @@ -1,7 +1,11 @@ > > TI Real Time Clock > > > > Required properties: > > -- compatible: "ti,da830-rtc" > > +- compatible: > > + - "ti,da830-rtc" - for RTC IP used similar to that on DA8xx SoC family. > > + - "ti,am3352-rtc" - for RTC IP used similar to that on AM335x SoC > > family. > > + This RTC IP has special WAKE-EN Register to enable > > + Wakeup generation for event Alarm. > > - reg: Address range of rtc register set > > - interrupts: rtc timer, alarm interrupts in order > > - interrupt-parent: phandle for the interrupt controller > > diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c > > index 761919d..666b0c2 100644 > > --- a/drivers/rtc/rtc-omap.c > > +++ b/drivers/rtc/rtc-omap.c > > @@ -72,6 +72,8 @@ > > #define OMAP_RTC_KICK0_REG 0x6c > > #define OMAP_RTC_KICK1_REG 0x70 > > > > +#define OMAP_RTC_IRQWAKEEN 0x7C > > + > > nit: letters in hex numbers are usually lower-case. Thanks for the review. V2 will soon follow. > > > Kevin > Regards, Gururaja ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH -next] net: ethernet: davinci_emac: remove redundant dev_err call in davinci_emac_probe()
On Tuesday 02 July 2013 06:27 AM, Wei Yongjun wrote: From: Wei Yongjun There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Signed-off-by: Wei Yongjun Acked-by: Mugunthan V N Regards Mugunthan V N ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH -next] net: ethernet: davinci_emac: remove redundant dev_err call in davinci_emac_probe()
On Tue, Jul 2, 2013 at 6:27 AM, Wei Yongjun wrote: > From: Wei Yongjun > > There is a error message within devm_ioremap_resource > already, so remove the dev_err call to avoid redundant > error message. > > Signed-off-by: Wei Yongjun Acked-by: Lad, Prabhakar Regards, --Prabhakar Lad ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/4] PCI: Add driver for i.MX6 PCI Express
On 7/2/2013 9:16 AM, Sean Cross wrote: >I may be wrong, but from these offset it seems to me that it is SNPS >controller. If yes, then please go through comments of >"[PATCH V1-10 0/4] PCIe support for Samsung Exynos5440 SoC" Exynos5440 appears to use the same port logic controller. However, the PHYs are different. I'm not exactly certain which comments you want me to notice in that series of patchsets, but I see references to splitting Exynos-specific code into its own project. Based on that, it seems like the best approach would be to: 1) Move Exynos code into its own file, say, pcie-exynos.c. This would leave only Synopsys-specific ATC code in pcie-designware.c 2) Rename generic exynos functions to reflect the fact that they're designware-generic functions. 3) Have pcie-imx.c reference this generic designware ATC code. I'll rework the patch and re-submit it following these three changes. Correct, Exactly these steps has to be done. But, Mohit might be doing similar work, so it would be better to get consensus on what has to be done. IMO, there should be three categories of functions. May be arnd can comment if we can do even something better. Group I: Initially, These functions should remain in pcie-designware.c (offcourse by changing exynos tag to dw). Latter on, we can see if some of them can even be moved to common pci layer. sys_to_pcie cfg_read cfg_write dw_pcie_prog_viewport_cfg0 dw_pcie_prog_viewport_cfg1 dw_pcie_prog_viewport_mem_outbound dw_pcie_prog_viewport_io_outbound dw_pcie_rd_other_conf dw_pcie_wr_other_conf dw_pcie_setup dw_pcie_valid_config dw_pcie_rd_conf dw_pcie_wd_conf dw_pcie_scan_bus dw_pcie_map_irq dw_pcie_setup_rc add_pcie_port (after a bit of generalization) dw_pcie_probe dw_pcie_remove Group II: These functions should still remain as dummy in pcie-designware.c , and should be classified as __week. So, each implementer of designware controller say Exynos/SPEAr/imx will have to define their own function to super-seed default dummy definitions. dw_readl_rc dw_writel_rc dw_pcie_rd_own_conf dw_pcie_wr_own_conf dw_pcie_link_up dw_pcie_host_init (will contain all platform specific and phy initialization) Group III: Functions specific to Exynos, which should move to pcie-exynos.c exynos_pcie_sideband_dbi_w_mode exynos_pcie_sideband_dbi_r_mode exynos_pcie_assert_core_reset exynos_pcie_deassert_core_reset exynos_pcie_assert_phy_reset exynos_pcie_deassert_phy_reset exynos_pcie_init_phy exynos_pcie_assert_reset exynos_pcie_establish_link @Mohit, See if you have BW then please take it further. arnd, are exynos patches applied to any branch of arm-soc git tree? Regards Pratyush ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re[2]: [PATCH v3 2/5] ARM: dts: imx27: Add imx framebuffer device
> On Fri, Jun 28, 2013 at 07:10:06PM +0400, Alexander Shiyan wrote:
> > > Signed-off-by: Markus Pargmann
> > > ---
> > > arch/arm/boot/dts/imx27.dtsi | 9 +
> > > 1 file changed, 9 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
> > > index 8603886..10dcbd3 100644
> > > --- a/arch/arm/boot/dts/imx27.dtsi
> > > +++ b/arch/arm/boot/dts/imx27.dtsi
> > > @@ -342,6 +342,15 @@
> > > reg = <0x1002 0x2>;
> > > ranges;
> > >
> > > + imxfb: fb@10021000 {
> >
> > If it can be fixed while applying, it would be right to use just "fb" here.
> > We now use a lot of devices without "imx"-prefix, so I do not see any need
> > to use it here.
>
> I actually prefer to use the block name if it's not a thing defined by
> ePAPR. In this case, it's "lcdc". But since "fb" is already used in
> compatible. Okay, I fixed it up by dropping "imx" prefix.
i.MX27 have a SLCDC module, so perhaps your proposed option (lcdc) is better.
---
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] of: Specify initrd location using 64-bit
On 07/01/2013 11:52 PM, Santosh Shilimkar wrote: > On some PAE architectures, the entire range of physical memory could reside > outside the 32-bit limit. These systems need the ability to specify the > initrd location using 64-bit numbers. > > This patch globally modifies the early_init_dt_setup_initrd_arch() function to > use 64-bit numbers instead of the current unsigned long. > > There has been quite a bit of debate about whether to use u64 or phys_addr_t. > It was concluded to stick to u64 to be consistent with rest of the device > tree code. As summarized by Geert, "The address to load the initrd is decided > by the bootloader/user and set at that point later in time. The dtb should not > be tied to the kernel you are booting" > > More details on the discussion can be found here: > https://lkml.org/lkml/2013/6/20/690 > https://lkml.org/lkml/2012/9/13/544 > > Cc: Grant Likely > Cc: Rob Herring > Cc: Geert Uytterhoeven > Cc: Sebastian Andrzej Siewior > Cc: Jean-Christophe PLAGNIOL-VILLARD > Cc: Vineet Gupta > Cc: Russell King > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Mark Salter > Cc: Aurelien Jacquiot > Cc: James Hogan > Cc: Michal Simek > Cc: Ralf Baechle > Cc: Jonas Bonn > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: x...@kernel.org > Cc: a...@kernel.org > Cc: Chris Zankel > Cc: Max Filippov > Cc: bige...@linutronix.de > Cc: robherri...@gmail.com > Cc: Nicolas Pitre > > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-c6x-...@linux-c6x.org > Cc: linux-m...@linux-mips.org > Cc: linuxppc-...@lists.ozlabs.org > Cc: linux-xte...@linux-xtensa.org > Cc: devicetree-discuss@lists.ozlabs.org > > Signed-off-by: Santosh Shilimkar > --- Acked-by: Vineet Gupta [For arch/arc bits] -Vineet ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/4] PCI: Add driver for i.MX6 PCI Express
On Monday, July 1, 2013 at 6:08 PM, Pratyush Anand wrote: > On 7/1/2013 12:45 PM, Sean Cross wrote: > > This adds a PCI Express port driver for the on-chip PCI Express port > > present on the i.MX6 SoC. It is based on the PCI Express driver available > > in the Freescale BSP. > > > > Signed-off-by: Sean Cross mailto:x...@kosagi.com)> > > --- > > > > ... > > > diff --git a/drivers/pci/pcie/pcie-imx.c b/drivers/pci/pcie/pcie-imx.c > > new file mode 100644 > > index 000..664679e > > --- /dev/null > > +++ b/drivers/pci/pcie/pcie-imx.c > > > > Should go to drivers/pci/host/ I'll pull from arm-soc rather than from Linus' tree and place the driver there instead. > > @@ -0,0 +1,1049 @@ > > +/* > > + * drivers/pci/pcie/pcie-imx.c > > + * > > > > ... > > > > +#define ATU_R_BaseAddress 0x900 > > +#define PCIE_PL_iATUVR (ATU_R_BaseAddress + 0x0) > > +#define PCIE_PL_iATURC1 (ATU_R_BaseAddress + 0x4) > > +#define PCIE_PL_iATURC2 (ATU_R_BaseAddress + 0x8) > > +#define PCIE_PL_iATURLBA (ATU_R_BaseAddress + 0xC) > > +#define PCIE_PL_iATURUBA (ATU_R_BaseAddress + 0x10) > > +#define PCIE_PL_iATURLA (ATU_R_BaseAddress + 0x14) > > +#define PCIE_PL_iATURLTA (ATU_R_BaseAddress + 0x18) > > +#define PCIE_PL_iATURUTA (ATU_R_BaseAddress + 0x1C) > > > > I may be wrong, but from these offset it seems to me that it is SNPS > controller. If yes, then please go through comments of > "[PATCH V1-10 0/4] PCIe support for Samsung Exynos5440 SoC" Exynos5440 appears to use the same port logic controller. However, the PHYs are different. I'm not exactly certain which comments you want me to notice in that series of patchsets, but I see references to splitting Exynos-specific code into its own project. Based on that, it seems like the best approach would be to: 1) Move Exynos code into its own file, say, pcie-exynos.c. This would leave only Synopsys-specific ATC code in pcie-designware.c 2) Rename generic exynos functions to reflect the fact that they're designware-generic functions. 3) Have pcie-imx.c reference this generic designware ATC code. I'll rework the patch and re-submit it following these three changes. -- Sean Cross ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 08/13] sound: sam9x5_wm8731: machine driver for at91sam9x5 wm8731 boards
Hi Richard,
Will move this patch before 5, 6, 7?
On 7/1/2013 16:39, Richard Genoud wrote:
From: Nicolas Ferre
Description of the Asoc machine driver for an at91sam9x5 based board
with a wm8731 audio DAC. Wm8731 is clocked by a crystal and used as a
master on the SSC/I2S interface. Its connections are a headphone jack
and an Line input jack.
[Richard: this is based on an old patch from Nicolas that I forward
ported and reworked to use only device tree]
Signed-off-by: Nicolas Ferre
Signed-off-by: Uwe Kleine-König
Signed-off-by: Richard Genoud
---
sound/soc/atmel/Kconfig | 12 ++
sound/soc/atmel/Makefile|2 +
sound/soc/atmel/sam9x5_wm8731.c | 232 +++
3 files changed, 246 insertions(+)
create mode 100644 sound/soc/atmel/sam9x5_wm8731.c
diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
index 3fdd87f..f24d601 100644
--- a/sound/soc/atmel/Kconfig
+++ b/sound/soc/atmel/Kconfig
@@ -13,6 +13,7 @@ config SND_ATMEL_SOC_PDC
config SND_ATMEL_SOC_DMA
tristate
depends on SND_ATMEL_SOC
+ select SND_SOC_DMAENGINE_PCM
config SND_ATMEL_SOC_SSC
tristate
@@ -32,6 +33,17 @@ config SND_AT91_SOC_SAM9G20_WM8731
Say Y if you want to add support for SoC audio on WM8731-based
AT91sam9g20 evaluation board.
+config SND_AT91_SOC_SAM9X5_WM8731
+ tristate "SoC Audio support for WM8731-based at91sam9x5 board"
+ depends on ATMEL_SSC && SND_ATMEL_SOC && SOC_AT91SAM9X5
+ select SND_ATMEL_SOC_SSC
+ select SND_ATMEL_SOC_DMA
+ select SND_ATMEL_SOC_PDC
Not need to select SND_ATMEL_SOC_PDC
+ select SND_SOC_WM8731
+ help
+ Say Y if you want to add support for audio SoC on an
+ at91sam9x5 based board that is using WM8731 codec.
+
config SND_AT91_SOC_AFEB9260
tristate "SoC Audio support for AFEB9260 board"
depends on ARCH_AT91 && ATMEL_SSC && ARCH_AT91 && MACH_AFEB9260 &&
SND_ATMEL_SOC
diff --git a/sound/soc/atmel/Makefile b/sound/soc/atmel/Makefile
index 41967cc..7784c09 100644
--- a/sound/soc/atmel/Makefile
+++ b/sound/soc/atmel/Makefile
@@ -11,6 +11,8 @@ obj-$(CONFIG_SND_ATMEL_SOC_SSC) += snd-soc-atmel_ssc_dai.o
# AT91 Machine Support
snd-soc-sam9g20-wm8731-objs := sam9g20_wm8731.o
+snd-soc-sam9x5-wm8731-objs := sam9x5_wm8731.o
obj-$(CONFIG_SND_AT91_SOC_SAM9G20_WM8731) += snd-soc-sam9g20-wm8731.o
+obj-$(CONFIG_SND_AT91_SOC_SAM9X5_WM8731) += snd-soc-sam9x5-wm8731.o
obj-$(CONFIG_SND_AT91_SOC_AFEB9260) += snd-soc-afeb9260.o
diff --git a/sound/soc/atmel/sam9x5_wm8731.c b/sound/soc/atmel/sam9x5_wm8731.c
new file mode 100644
index 000..83ca457
--- /dev/null
+++ b/sound/soc/atmel/sam9x5_wm8731.c
@@ -0,0 +1,232 @@
+/*
+ * sam9x5_wm8731 -- SoC audio for AT91SAM9X5-based boards
+ * that are using WM8731 as codec.
+ *
+ * Copyright (C) 2011 Atmel,
+ * Nicolas Ferre
+ *
+ * Based on sam9g20_wm8731.c by:
+ * Sedji Gaouaou
+ *
+ * GPL
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "../codecs/wm8731.h"
+#include "atmel-pcm.h"
+#include "atmel_ssc_dai.h"
+
+#define MCLK_RATE 12288000
+
+#define DRV_NAME "sam9x5-snd-wm8731"
+
+/*
+ * Audio paths on at91sam9x5ek board:
+ *
+ * |A| > | | ---R> Headphone Jack
+ * |T| <\| WM | ---L--/
+ * |9| ---> CLK <--> | 8751 | <--R- Line In Jack
+ * |1| < | | <--L--/
+ */
+static const struct snd_soc_dapm_widget at91sam9x5ek_dapm_widgets[] = {
+ SND_SOC_DAPM_HP("Headphone Jack", NULL),
+ SND_SOC_DAPM_LINE("Line In Jack", NULL),
+};
+
+/*
+ * Logic for a wm8731 as connected on a at91sam9x5 based board.
+ */
+static int at91sam9x5ek_wm8731_init(struct snd_soc_pcm_runtime *rtd)
+{
+ struct snd_soc_codec *codec = rtd->codec;
+ struct snd_soc_dai *codec_dai = rtd->codec_dai;
+ struct snd_soc_dapm_context *dapm = &codec->dapm;
+ struct device *dev = rtd->dev;
+ int ret;
+
+ dev_dbg(dev, "ASoC: at91sam9x5ek_wm8731_init() called\n");
+
+ /*
+* remove some not supported rates in relation with clock
+* provided to the wm8731 codec
+*/
+ switch (MCLK_RATE) {
+ case 12288000:
+ codec_dai->driver->playback.rates &= SNDRV_PCM_RATE_8000 |
+SNDRV_PCM_RATE_32000 |
+SNDRV_PCM_RATE_48000 |
+SNDRV_PCM_RATE_96000;
+ codec_dai->driver->capture.rates &= SNDRV_PCM_RATE_8000 |
+ SNDRV_PCM_RATE_32000 |
+ SNDRV_PCM_RATE_48000 |
+ SNDRV_PCM_RATE_96000;
+
Re: [RFC PATCH 01/13] misc: atmel_ssc: add device tree DMA support
Hi Richard, On 7/1/2013 16:39, Richard Genoud wrote: The ssc device has to fill the at_dma_slave structure with the device tree informations. Doing a of_dma_request_slave_channel()+dma_release_channel() for that seems wrong (or at least not very clean). Please hold on of this, as to the ASoC dmaengine will deal with this. So, we not need do it manually. Now, I am working on it. And will send out the patch soon after testing OK. Signed-off-by: Richard Genoud --- drivers/misc/atmel-ssc.c| 56 +++ include/linux/atmel-ssc.h |2 ++ include/linux/platform_data/dma-atmel.h |2 ++ 3 files changed, 60 insertions(+) Best Regards, Bo Shen ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 02/13] misc: atmel_ssc: keep the count of pdev->id
Hi Richard,
On 7/1/2013 16:39, Richard Genoud wrote:
With device tree, pdev->id is always -1, so we introduce a local
counter.
Signed-off-by: Richard Genoud
---
drivers/misc/atmel-ssc.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index 3afbd82..d1ec5ab 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -173,6 +173,12 @@ out:
return err;
}
+/* counter of ssc devive instances.
+ * With device tree pdev->id is always -1, so we have to keep the
+ * count ourselves
+ */
+static int ssc_device_id;
Do we really need this? If Yes, would it better to get from device
through of_alias_get_id?
+
static int ssc_probe(struct platform_device *pdev)
{
struct resource *regs;
@@ -235,6 +241,7 @@ static int ssc_probe(struct platform_device *pdev)
}
spin_lock(&user_lock);
+ pdev->id = ssc_device_id++;
list_add_tail(&ssc->list, &ssc_list);
spin_unlock(&user_lock);
Best Regards,
Bo Shen
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 03/13] ARM: at91: DTS: sam9x5: add clock for SSC DT entry
Hi Richard,
On 7/1/2013 16:39, Richard Genoud wrote:
Signed-off-by: Richard Genoud
---
arch/arm/mach-at91/at91sam9x5.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-at91/at91sam9x5.c b/arch/arm/mach-at91/at91sam9x5.c
index 2abee66..191eb4b 100644
--- a/arch/arm/mach-at91/at91sam9x5.c
+++ b/arch/arm/mach-at91/at91sam9x5.c
@@ -233,6 +233,7 @@ static struct clk_lookup periph_clocks_lookups[] = {
CLKDEV_CON_DEV_ID("mci_clk", "f000c000.mmc", &mmc1_clk),
CLKDEV_CON_DEV_ID("dma_clk", "ec00.dma-controller", &dma0_clk),
CLKDEV_CON_DEV_ID("dma_clk", "ee00.dma-controller", &dma1_clk),
+ CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.0", &ssc_clk),
Actually, we don't use this anymore. Am I right?
CLKDEV_CON_DEV_ID("pclk", "f001.ssc", &ssc_clk),
CLKDEV_CON_DEV_ID(NULL, "f801.i2c", &twi0_clk),
CLKDEV_CON_DEV_ID(NULL, "f8014000.i2c", &twi1_clk),
Best Regards,
Bo Shen
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv3 2/3] ARM: mxs: cfa10049: Switch bus i2c1 to bitbanging
Hi Alexandre, On Mon, Jun 24, 2013 at 2:24 PM, Alexandre Belloni wrote: > From: Maxime Ripard > > The ADCs connected to this bus have been experiencing some timeout > issues when using the iMX28 i2c controller. Switching back to bitbanging > solves this. Are you able to use the mxs i2c controller instead of bitbang if you use this patch? http://www.spinics.net/lists/stable/msg13202.html Regards, Fabio Estevam ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH -next] net: ethernet: davinci_emac: remove redundant dev_err call in davinci_emac_probe()
From: Wei Yongjun
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun
---
drivers/net/ethernet/ti/davinci_emac.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c
b/drivers/net/ethernet/ti/davinci_emac.c
index f118d71..07b176b 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1870,7 +1870,6 @@ static int davinci_emac_probe(struct platform_device
*pdev)
priv->emac_base_phys = res->start + pdata->ctrl_reg_offset;
priv->remap_addr = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(priv->remap_addr)) {
- dev_err(&pdev->dev, "unable to map IO\n");
rc = PTR_ERR(priv->remap_addr);
goto no_pdata;
}
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH -next] [SCSI] ufshcd-pltfrm: remove redundant dev_err call in ufshcd_pltfrm_probe()
From: Wei Yongjun
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun
---
drivers/scsi/ufs/ufshcd-pltfrm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index c42db40..2bd7417 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -110,7 +110,6 @@ static int ufshcd_pltfrm_probe(struct platform_device *pdev)
mmio_base = devm_ioremap_resource(dev, mem_res);
if (IS_ERR(mmio_base)) {
- dev_err(dev, "memory map failed\n");
err = PTR_ERR(mmio_base);
goto out;
}
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH -next] spi: tegra114: remove redundant dev_err call in tegra_spi_probe()
From: Wei Yongjun
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun
---
drivers/spi/spi-tegra114.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
index e8f542a..8c99c00 100644
--- a/drivers/spi/spi-tegra114.c
+++ b/drivers/spi/spi-tegra114.c
@@ -1068,7 +1068,6 @@ static int tegra_spi_probe(struct platform_device *pdev)
tspi->base = devm_ioremap_resource(&pdev->dev, r);
if (IS_ERR(tspi->base)) {
ret = PTR_ERR(tspi->base);
- dev_err(&pdev->dev, "ioremap failed: err = %d\n", ret);
goto exit_free_master;
}
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] of: Specify initrd location using 64-bit
On 07/01/2013 01:20 PM, Santosh Shilimkar wrote:
> On some PAE architectures, the entire range of physical memory could reside
> outside the 32-bit limit. These systems need the ability to specify the
> initrd location using 64-bit numbers.
>
> This patch globally modifies the early_init_dt_setup_initrd_arch() function to
> use 64-bit numbers instead of the current unsigned long.
>
> There has been quite a bit of debate about whether to use u64 or phys_addr_t.
> It was concluded to stick to u64 to be consistent with rest of the device
> tree code. As summarized by Geert, "The address to load the initrd is decided
> by the bootloader/user and set at that point later in time. The dtb should not
> be tied to the kernel you are booting"
That was quoting me. Otherwise:
Acked-by: Rob Herring
Unless Grant feels compelled to pick this up for 3.11, I think it has to
wait for 3.12.
Rob
>
> More details on the discussion can be found here:
> https://lkml.org/lkml/2013/6/20/690
> https://lkml.org/lkml/2012/9/13/544
>
> Cc: Grant Likely
> Cc: Rob Herring
> Cc: Geert Uytterhoeven
> Cc: Sebastian Andrzej Siewior
> Cc: Jean-Christophe PLAGNIOL-VILLARD
> Cc: Vineet Gupta
> Cc: Russell King
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Mark Salter
> Cc: Aurelien Jacquiot
> Cc: James Hogan
> Cc: Michal Simek
> Cc: Ralf Baechle
> Cc: Jonas Bonn
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: x...@kernel.org
> Cc: a...@kernel.org
> Cc: Chris Zankel
> Cc: Max Filippov
> Cc: bige...@linutronix.de
> Cc: robherri...@gmail.com
> Cc: Nicolas Pitre
>
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-c6x-...@linux-c6x.org
> Cc: linux-m...@linux-mips.org
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: linux-xte...@linux-xtensa.org
> Cc: devicetree-discuss@lists.ozlabs.org
>
> Signed-off-by: Santosh Shilimkar
> ---
> arch/arc/mm/init.c|5 ++---
> arch/arm/mm/init.c|2 +-
> arch/arm64/mm/init.c |3 +--
> arch/c6x/kernel/devicetree.c |3 +--
> arch/metag/mm/init.c |5 ++---
> arch/microblaze/kernel/prom.c |3 +--
> arch/mips/kernel/prom.c |3 +--
> arch/openrisc/kernel/prom.c |3 +--
> arch/powerpc/kernel/prom.c|3 +--
> arch/x86/kernel/devicetree.c |3 +--
> arch/xtensa/kernel/setup.c|3 +--
> drivers/of/fdt.c | 10 ++
> include/linux/of_fdt.h|3 +--
> 13 files changed, 20 insertions(+), 29 deletions(-)
>
> diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
> index 4a17736..7991e08 100644
> --- a/arch/arc/mm/init.c
> +++ b/arch/arc/mm/init.c
> @@ -157,9 +157,8 @@ void __init free_initrd_mem(unsigned long start, unsigned
> long end)
> #endif
>
> #ifdef CONFIG_OF_FLATTREE
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> - pr_err("%s(%lx, %lx)\n", __func__, start, end);
> + pr_err("%s(%llx, %llx)\n", __func__, start, end);
> }
> #endif /* CONFIG_OF_FLATTREE */
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 9a5cdc0..afeaef7 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -76,7 +76,7 @@ static int __init parse_tag_initrd2(const struct tag *tag)
> __tagtable(ATAG_INITRD2, parse_tag_initrd2);
>
> #ifdef CONFIG_OF_FLATTREE
> -void __init early_init_dt_setup_initrd_arch(unsigned long start, unsigned
> long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> phys_initrd_start = start;
> phys_initrd_size = end - start;
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index f497ca7..7047708 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -44,8 +44,7 @@ static unsigned long phys_initrd_size __initdata = 0;
>
> phys_addr_t memstart_addr __read_mostly = 0;
>
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> phys_initrd_start = start;
> phys_initrd_size = end - start;
> diff --git a/arch/c6x/kernel/devicetree.c b/arch/c6x/kernel/devicetree.c
> index bdb56f0..287d0e6 100644
> --- a/arch/c6x/kernel/devicetree.c
> +++ b/arch/c6x/kernel/devicetree.c
> @@ -33,8 +33,7 @@ void __init early_init_devtree(void *params)
>
>
> #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> initrd_start = (unsigned long)__va(start);
> initrd_end = (unsigned long)__va(end);
> diff --git a/arch/metag/mm/init.c b/arch/metag/mm/init.c
> index d05b845..bdc4811 100644
> --- a/arch/metag/mm/init.c
> +++ b/arch/metag/mm/init.c
> @@ -419,10 +419,9 @@ void free_initrd_mem(unsigned long start,
Re: [RFC] wlcore: sdio: add wilink clock providers
On Mon, 2013-07-01 at 23:46 +0300, Felipe Balbi wrote:
> Hi,
>
> On Mon, Jul 01, 2013 at 10:34:10PM +0300, Luciano Coelho wrote:
> > diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
> > b/arch/arm/boot/dts/omap4-panda-common.dtsi
> > index 670c3ce..7f061b8 100644
> > --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> > +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> > @@ -65,11 +65,19 @@
> > enable-active-high;
> > };
> >
> > +
> > wlan {
> > -compatible = "ti,wilink6";
> > -interrupt-parent = <&gpio2>;
> > -interrupts = <21 0x4>; /* gpio line 53, high level triggered */
> > -refclock = <2>;/* 38.4 MHz */
> > + compatible = "ti,wilink6";
> > + interrupt-parent = <&gpio2>;
> > + interrupts = <21 0x4>; /* gpio line 53, high level triggered */
> > + clocks = <&refclock>;
> > + clock-names = "refclock";
>
> hmmm, shouldn't you provide both clocks (refclock and tcx0clock)
> explicitly here ?
No, not needed for Panda. Panda uses WiLink6 and only the refclock
needs to be provided.
> Also, you should probably make it clear that the WiLink module is fed by
> the 32K sync clock just to make sure clock usecounts are correctly
> incremented ?
Hmmm, yes, that is probably a good idea. At least to make sure
everything is initialized properly before the WiLink module is up and
running. I'll look into it and eventually add in a separate patch.
Thanks for your comments!
--
Luca.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC] wlcore: sdio: add wilink clock providers
Hi,
On Mon, Jul 01, 2013 at 10:34:10PM +0300, Luciano Coelho wrote:
> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
> b/arch/arm/boot/dts/omap4-panda-common.dtsi
> index 670c3ce..7f061b8 100644
> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> @@ -65,11 +65,19 @@
> enable-active-high;
> };
>
> +
> wlan {
> - compatible = "ti,wilink6";
> - interrupt-parent = <&gpio2>;
> - interrupts = <21 0x4>; /* gpio line 53, high level triggered */
> - refclock = <2>;/* 38.4 MHz */
> + compatible = "ti,wilink6";
> + interrupt-parent = <&gpio2>;
> + interrupts = <21 0x4>; /* gpio line 53, high level triggered */
> + clocks = <&refclock>;
> + clock-names = "refclock";
hmmm, shouldn't you provide both clocks (refclock and tcx0clock)
explicitly here ?
Also, you should probably make it clear that the WiLink module is fed by
the 32K sync clock just to make sure clock usecounts are correctly
incremented ?
--
balbi
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V3 2/3] phy: Add driver for Exynos DP PHY
On 07/01/2013 07:24 AM, Jingoo Han wrote:
Add a PHY provider driver for the Samsung Exynos SoC DP PHY.
Signed-off-by: Jingoo Han
Cc: Sylwester Nawrocki
Acked-by: Felipe Balbi
---
.../devicetree/bindings/phy/samsung-phy.txt|8 ++
drivers/phy/Kconfig|5 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos-dp-video.c | 118
4 files changed, 132 insertions(+)
create mode 100644 drivers/phy/phy-exynos-dp-video.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 5ff208c..3fb656a 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -12,3 +12,11 @@ the PHY specifier identifies the PHY and its meaning is as
follows:
1 - MIPI DSIM 0,
2 - MIPI CSIS 1,
3 - MIPI DSIM 1.
+
+Samsung EXYNOS SoC series DP PHY
I would make it "Samsung EXYNOS SoC series Display Port PHY"
+-
+
+Required properties:
+- compatible : should be "samsung,exynos5250-dp-video-phy";
+- reg : offset and length of the DP PHY register set;
+- #phy-cells : from the generic phy bindings, must be 0;
s/phy/PHY ?
\ No newline at end of file
Missing new line character.
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 6f446d0..760f55a 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -19,4 +19,9 @@ config PHY_EXYNOS_MIPI_VIDEO
help
Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung
S5P and EXYNOS SoCs.
+
+config PHY_EXYNOS_DP_VIDEO
+ tristate "EXYNOS SoC series DP PHY driver"
"EXYNOS SoC series Display Port PHY driver" ?
+ help
+ Support for DP PHY found on Samsung EXYNOS SoCs.
s/DP/Display Port ?
endif
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 71d8841..0fd1340 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_GENERIC_PHY) += phy-core.o
obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
+obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
diff --git a/drivers/phy/phy-exynos-dp-video.c
b/drivers/phy/phy-exynos-dp-video.c
new file mode 100644
index 000..75e1d11
--- /dev/null
+++ b/drivers/phy/phy-exynos-dp-video.c
@@ -0,0 +1,118 @@
+/*
+ * Samsung EXYNOS SoC series DP PHY driver
s/DP/Display Port ?
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Jingoo Han
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* DPTX_PHY_CONTROL register */
+#define EXYNOS_DPTX_PHY_ENABLE (1<< 0)
+
+struct exynos_dp_video_phy {
+ void __iomem *regs;
+};
+
+static int __set_phy_state(struct exynos_dp_video_phy *state, unsigned int on)
+{
+ void __iomem *addr;
How about just dropping this local variable ?
+ u32 reg;
+
+ addr = state->regs;
+
+ reg = readl(addr);
+ if (on)
+ reg |= EXYNOS_DPTX_PHY_ENABLE;
+ else
+ reg&= ~EXYNOS_DPTX_PHY_ENABLE;
+ writel(reg, addr);
+
+ return 0;
+}
+
+static int exynos_dp_video_phy_power_on(struct phy *phy)
+{
+ struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
+
+ return __set_phy_state(state, 1);
+}
+
+static int exynos_dp_video_phy_power_off(struct phy *phy)
+{
+ struct exynos_dp_video_phy *state = phy_get_drvdata(phy);
+
+ return __set_phy_state(state, 0);
+}
+
+static struct phy_ops exynos_dp_video_phy_ops = {
+ .power_on = exynos_dp_video_phy_power_on,
+ .power_off = exynos_dp_video_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+static int exynos_dp_video_phy_probe(struct platform_device *pdev)
+{
+ struct exynos_dp_video_phy *state;
+ struct device *dev =&pdev->dev;
+ struct resource *res;
+ struct phy_provider *phy_provider;
+ struct phy *phy;
+
+ state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+ state->regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(state->regs))
+ return PTR_ERR(state->regs);
+
+ dev_set_drvdata(dev, state);
I can't see any corresponding dev_get_drvdata(), it should be safe
to remove this assignment.
+ phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+ if (IS_ERR(phy_provider))
+ return PTR_ERR(phy_provider);
+
+ phy = devm_phy_create(dev, 0,&exynos_dp_video_phy_ops, "dp");
The label could be NULL, since there is no n
Re: [PATCH V3 3/3] video: exynos_dp: Use the generic PHY driver
Hi Jingoo,
On 07/01/2013 07:24 AM, Jingoo Han wrote:
Use the generic PHY API instead of the platform callback to control
the DP PHY. The 'phy_label' field is added to the platform data
structure to allow PHY lookup on non-dt platforms.
Since Exynos is currently a dt-only platform upstream, how about
first making a pre-requisite patch that would remove support for
non-dt platforms from this driver ? I think you could now move the
content of file include/video/exynos_dp.h to e.g. drivers/video/
exynos/exynos_dp_core.h and remove the public exynos_dp.h file.
pdata->phy_init/exit could also be dropped and you wouldn't need
to care about non-dt support with the generic PHY API.
Signed-off-by: Jingoo Han
Acked-by: Felipe Balbi
---
.../devicetree/bindings/video/exynos_dp.txt| 23 +---
drivers/video/exynos/exynos_dp_core.c | 118 ++--
drivers/video/exynos/exynos_dp_core.h |2 +
include/video/exynos_dp.h |6 +-
4 files changed, 21 insertions(+), 128 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
b/Documentation/devicetree/bindings/video/exynos_dp.txt
index 84f10c1..71645dc 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -1,17 +1,6 @@
The Exynos display port interface should be configured based on
the type of panel connected to it.
-We use two nodes:
- -dp-controller node
- -dptx-phy node(defined inside dp-controller node)
-
-For the DP-PHY initialization, we use the dptx-phy node.
-Required properties for dptx-phy:
- -reg:
- Base address of DP PHY register.
- -samsung,enable-mask:
- The bit-mask used to enable/disable DP PHY.
-
For the Panel initialization, we read data from dp-controller node.
Required properties for dp-controller:
-compatible:
@@ -25,6 +14,10 @@ Required properties for dp-controller:
from common clock binding: handle to dp clock.
-clock-names:
from common clock binding: Shall be "dp".
+ -phys:
+ from general phy binding: the phandle for the PHY device.
+ -phy-names:
+ from general phy binding: Should be "dp".
-interrupt-parent:
phandle to Interrupt combiner node.
-samsung,color-space:
@@ -67,12 +60,8 @@ SOC specific portion:
interrupt-parent =<&combiner>;
clocks =<&clock 342>;
clock-names = "dp";
-
- dptx-phy {
- reg =<0x10040720>;
- samsung,enable-mask =<1>;
- };
-
+ phys =<&dp_phy>;
+ phy-names = "dp";
};
Board Specific portion:
diff --git a/drivers/video/exynos/exynos_dp_core.c
b/drivers/video/exynos/exynos_dp_core.c
index 12bbede..bac515b 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
@@ -960,84 +961,15 @@ static struct exynos_dp_platdata
*exynos_dp_dt_parse_pdata(struct device *dev)
return ERR_PTR(-EINVAL);
}
- return pd;
-}
-
-static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
-{
- struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
- u32 phy_base;
- int ret = 0;
-
- dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
- if (!dp_phy_node) {
- dev_err(dp->dev, "could not find dptx-phy node\n");
- return -ENODEV;
- }
-
- if (of_property_read_u32(dp_phy_node, "reg",&phy_base)) {
- dev_err(dp->dev, "failed to get reg for dptx-phy\n");
- ret = -EINVAL;
- goto err;
- }
-
- if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
- &dp->enable_mask)) {
- dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
- ret = -EINVAL;
- goto err;
- }
-
- dp->phy_addr = ioremap(phy_base, SZ_4);
- if (!dp->phy_addr) {
- dev_err(dp->dev, "failed to ioremap dp-phy\n");
- ret = -ENOMEM;
- goto err;
- }
-
-err:
- of_node_put(dp_phy_node);
-
- return ret;
-}
-
-static void exynos_dp_phy_init(struct exynos_dp_device *dp)
-{
- u32 reg;
-
- reg = __raw_readl(dp->phy_addr);
- reg |= dp->enable_mask;
- __raw_writel(reg, dp->phy_addr);
-}
-
-static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
-{
- u32 reg;
+ pd->phy_label = "dp";
- reg = __raw_readl(dp->phy_addr);
- reg&= ~(dp->enable_mask);
- __raw_writel(reg, dp->phy_addr);
+ return pd;
}
I'm afraid you cannot simply remove the above code, the original binding
still needs to be suppo
[RFC] wlcore: sdio: add wilink clock providers
Add refclock and tcxoclock as clock providers in WiLink. These clocks
are not accesible outside the WiLink module, but they are registered
in the clock framework anyway. Only the WiLink chip consumes these
clocks.
In theory, the WiLink chip could be connected to external clocks
instead of using these internal clocks, so make the clock consumer
code generic enough. If external clocks are used, then the internal
clock device tree nodes are not necessary, but the external ones must
be specified.
Signed-off-by: Luciano Coelho
---
Hi,
I came up with this code, trying to make the WiLink clocks definitions
as generic as possible and use existing fixed-clock bindings. This
looks relatively clean to me, even though it adds some complexity.
But I think it's better than the original bindings I had defined.
I still need to take care of the XTAL/not-XTAl boolean, but I will do
that separately.
This patch will be split (to take away the Panda DTS part) and
squashed in other patches in my series.
Please let me know what you think.
--
Cheers,
Luca.
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 ---
drivers/net/wireless/ti/wlcore/sdio.c | 43 ++---
2 files changed, 51 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 670c3ce..7f061b8 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -65,11 +65,19 @@
enable-active-high;
};
+
wlan {
-compatible = "ti,wilink6";
-interrupt-parent = <&gpio2>;
-interrupts = <21 0x4>; /* gpio line 53, high level triggered */
-refclock = <2>;/* 38.4 MHz */
+ compatible = "ti,wilink6";
+ interrupt-parent = <&gpio2>;
+ interrupts = <21 0x4>; /* gpio line 53, high level triggered */
+ clocks = <&refclock>;
+ clock-names = "refclock";
+
+ refclock: refclock {
+ compatible = "ti,wilink-clock";
+ #clock-cells = <0>;
+ clock-frequency = <3840>;
+ };
};
};
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 5b08620..60fce49 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include "wlcore.h"
#include "wl12xx_80211.h"
@@ -52,6 +53,7 @@ static bool dump = false;
struct wl12xx_sdio_glue {
struct device *dev;
struct platform_device *core;
+ struct clk *refclock, *tcxoclock;
};
static const struct sdio_device_id wl1271_devices[] = {
@@ -214,10 +216,16 @@ static struct wl1271_if_operations sdio_ops = {
.set_block_size = wl1271_sdio_set_block_size,
};
+static const struct of_device_id wlcore_sdio_of_clk_match_table[] = {
+ { .compatible = "ti,wilink-clock" },
+};
+
static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device
*dev)
{
struct wl12xx_platform_data *pdata;
struct device_node *np = dev->of_node;
+ struct device_node *clock_node;
+ struct wl12xx_sdio_glue *glue = sdio_get_drvdata(dev_to_sdio_func(dev));
if (!np) {
np = of_find_matching_node(NULL, dev->driver->of_match_table);
@@ -241,11 +249,28 @@ static struct wl12xx_platform_data
*wlcore_get_pdata_from_of(struct device *dev)
goto out_free;
}
+ for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
+ of_fixed_clk_setup(clock_node);
+
/* TODO: make sure we have this when needed (ie. for WL6 and WL7) */
- of_property_read_u32(np, "refclock", &pdata->ref_clock_freq);
+ glue->refclock = of_clk_get_by_name(np, "refclock");
+ if (IS_ERR(glue->refclock)) {
+ dev_err(dev, "couldn't find refclock on the device tree\n");
+ glue->refclock = NULL;
+ } else {
+ clk_prepare_enable(glue->refclock);
+ pdata->ref_clock_freq = clk_get_rate(glue->refclock);
+ }
/* TODO: make sure we have this when needed (ie. for WL7) */
- of_property_read_u32(np, "tcxoclock", &pdata->tcxo_clock_freq);
+ glue->tcxoclock = of_clk_get_by_name(np, "tcxoclock");
+ if (IS_ERR(glue->tcxoclock)) {
+ dev_err(dev, "couldn't find tcxoclock on the device tree\n");
+ glue->tcxoclock = NULL;
+ } else {
+ clk_prepare_enable(glue->tcxoclock);
+ pdata->ref_clock_freq = clk_get_rate(glue->tcxoclock);
+ }
goto out;
@@ -291,6 +316,8 @@ static int wl1271_probe(struct sdio_func *func,
/* Use block mode for transferring over one block size of data */
func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MOD
[PATCH] of/platform: Staticize of_platform_device_create_pdata()
From: Mark Brown It is not used outside of this file so doesn't need to be in the global namespace. Signed-off-by: Mark Brown --- drivers/of/platform.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/of/platform.c b/drivers/of/platform.c index e0a6514..b0d1ff8 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -196,7 +196,7 @@ EXPORT_SYMBOL(of_device_alloc); * Returns pointer to created platform device, or NULL if a device was not * registered. Unavailable devices will not get registered. */ -struct platform_device *of_platform_device_create_pdata( +static struct platform_device *of_platform_device_create_pdata( struct device_node *np, const char *bus_id, void *platform_data, -- 1.8.3.1 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] leds: Add device tree binding for pca9633
On Thu, Jun 27, 2013 at 7:24 AM, Tony Lindgren wrote:
> * Tony Lindgren [130627 00:28]:
>> * Bryan Wu [130626 16:53]:
>> > On Wed, Jun 26, 2013 at 7:17 AM, Tony Lindgren wrote:
>> > > @@ -22,6 +22,7 @@
>> > > #include
>> > > #include
>> > > #include
>> > > +#include
>> > > #include
>> > >
>> > > /* LED select registers determine the source that drives LED outputs */
>> > > @@ -93,6 +94,61 @@ static void pca9633_led_set(struct led_classdev
>> > > *led_cdev,
>> > > schedule_work(&pca9633->work);
>> > > }
>> > >
>> > > +#ifdef CONFIG_OF
>> >
>> > Shall we use "#if IS_ENABLED(CONFIG_OF)", as Grant pointed out recently.
>>
>> Thanks will do, I'll also add the push-pull vs totem pole binding
>> as that can be quite crucial for some hardware configurations.
>
> Here's the updated patch.
>
> Regards,
>
> Tony
>
Thanks, I merged it into my -devel branch. And it targets for 3.12
merge window, since 3.11 merge window opened right now.
-Bryan
>
> From: Tony Lindgren
> Date: Wed, 26 Jun 2013 15:52:49 +0300
> Subject: [PATCH] leds: Add device tree binding for pca9633
>
> Similar to tca6507, we can just parse the standard LED
> properties for pca9633.
>
> Tested on a pca9632, which is compatible with pca9633.
>
> Signed-off-by: Tony Lindgren
>
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/pca9633.txt
> @@ -0,0 +1,45 @@
> +LEDs connected to pca9633 or pca9632
> +
> +Required properties:
> +- compatible : should be : "nxp,pca963x"
> +
> +Optional properties:
> +- nxp,totem-pole : use totem pole (push-pull) instead of default open-drain
> +
> +Each led is represented as a sub-node of the nxp,pca9633 device.
> +
> +LED sub-node properties:
> +- label : (optional) see Documentation/devicetree/bindings/leds/common.txt
> +- reg : number of LED line (could be from 0 to 4)
> +- linux,default-trigger : (optional)
> + see Documentation/devicetree/bindings/leds/common.txt
> +
> +Examples:
> +
> +pca9632: pca9632 {
> + compatible = "nxp,pca9632", "nxp,pca963x";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x62>;
> +
> + red@0 {
> + label = "red";
> + reg = <0>;
> + linux,default-trigger = "none";
> + };
> + green@1 {
> + label = "green";
> + reg = <1>;
> + linux,default-trigger = "none";
> + };
> + blue@2 {
> + label = "blue";
> + reg = <2>;
> + linux,default-trigger = "none";
> + };
> + unused@3 {
> + label = "unused";
> + reg = <3>;
> + linux,default-trigger = "none";
> + };
> +};
> --- a/drivers/leds/leds-pca9633.c
> +++ b/drivers/leds/leds-pca9633.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> /* LED select registers determine the source that drives LED outputs */
> @@ -93,6 +94,67 @@ static void pca9633_led_set(struct led_classdev *led_cdev,
> schedule_work(&pca9633->work);
> }
>
> +#if IS_ENABLED(CONFIG_OF)
> +static struct pca9633_platform_data *
> +pca9633_dt_init(struct i2c_client *client)
> +{
> + struct device_node *np = client->dev.of_node, *child;
> + struct pca9633_platform_data *pdata;
> + struct led_info *pca9633_leds;
> + int count;
> +
> + count = of_get_child_count(np);
> + if (!count || count > 4)
> + return ERR_PTR(-ENODEV);
> +
> + pca9633_leds = devm_kzalloc(&client->dev,
> + sizeof(struct led_info) * count, GFP_KERNEL);
> + if (!pca9633_leds)
> + return ERR_PTR(-ENOMEM);
> +
> + for_each_child_of_node(np, child) {
> + struct led_info led;
> + u32 reg;
> + int res;
> +
> + led.name =
> + of_get_property(child, "label", NULL) ? : child->name;
> + led.default_trigger =
> + of_get_property(child, "linux,default-trigger", NULL);
> + res = of_property_read_u32(child, "reg", ®);
> + if (res != 0)
> + continue;
> + pca9633_leds[reg] = led;
> + }
> + pdata = devm_kzalloc(&client->dev,
> +sizeof(struct pca9633_platform_data),
> GFP_KERNEL);
> + if (!pdata)
> + return ERR_PTR(-ENOMEM);
> +
> + pdata->leds.leds = pca9633_leds;
> + pdata->leds.num_leds = count;
> +
> + /* default to open-drain unless totem pole (push-pull) is specified */
> + if (of_property_read_bool(np, "nxp,totem-pole"))
> + pdata->outdrv = PCA9633_TOTEM_POLE;
> + else
> + pdata->outdrv = PCA9633_OPEN_DRAIN;
> +
> + return pdata;
> +}
> +
> +static const struct of_device_id of_pca9633_match[] = {
> + { .compatible = "nxp,pca963x", },
> + {},
> +};
> +#else
> +static struct pca9633_pla
[PATCH v2] of: Specify initrd location using 64-bit
On some PAE architectures, the entire range of physical memory could reside
outside the 32-bit limit. These systems need the ability to specify the
initrd location using 64-bit numbers.
This patch globally modifies the early_init_dt_setup_initrd_arch() function to
use 64-bit numbers instead of the current unsigned long.
There has been quite a bit of debate about whether to use u64 or phys_addr_t.
It was concluded to stick to u64 to be consistent with rest of the device
tree code. As summarized by Geert, "The address to load the initrd is decided
by the bootloader/user and set at that point later in time. The dtb should not
be tied to the kernel you are booting"
More details on the discussion can be found here:
https://lkml.org/lkml/2013/6/20/690
https://lkml.org/lkml/2012/9/13/544
Cc: Grant Likely
Cc: Rob Herring
Cc: Geert Uytterhoeven
Cc: Sebastian Andrzej Siewior
Cc: Jean-Christophe PLAGNIOL-VILLARD
Cc: Vineet Gupta
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Salter
Cc: Aurelien Jacquiot
Cc: James Hogan
Cc: Michal Simek
Cc: Ralf Baechle
Cc: Jonas Bonn
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: x...@kernel.org
Cc: a...@kernel.org
Cc: Chris Zankel
Cc: Max Filippov
Cc: bige...@linutronix.de
Cc: robherri...@gmail.com
Cc: Nicolas Pitre
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-c6x-...@linux-c6x.org
Cc: linux-m...@linux-mips.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-xte...@linux-xtensa.org
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Santosh Shilimkar
---
arch/arc/mm/init.c|5 ++---
arch/arm/mm/init.c|2 +-
arch/arm64/mm/init.c |3 +--
arch/c6x/kernel/devicetree.c |3 +--
arch/metag/mm/init.c |5 ++---
arch/microblaze/kernel/prom.c |3 +--
arch/mips/kernel/prom.c |3 +--
arch/openrisc/kernel/prom.c |3 +--
arch/powerpc/kernel/prom.c|3 +--
arch/x86/kernel/devicetree.c |3 +--
arch/xtensa/kernel/setup.c|3 +--
drivers/of/fdt.c | 10 ++
include/linux/of_fdt.h|3 +--
13 files changed, 20 insertions(+), 29 deletions(-)
diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
index 4a17736..7991e08 100644
--- a/arch/arc/mm/init.c
+++ b/arch/arc/mm/init.c
@@ -157,9 +157,8 @@ void __init free_initrd_mem(unsigned long start, unsigned
long end)
#endif
#ifdef CONFIG_OF_FLATTREE
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
- pr_err("%s(%lx, %lx)\n", __func__, start, end);
+ pr_err("%s(%llx, %llx)\n", __func__, start, end);
}
#endif /* CONFIG_OF_FLATTREE */
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 9a5cdc0..afeaef7 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -76,7 +76,7 @@ static int __init parse_tag_initrd2(const struct tag *tag)
__tagtable(ATAG_INITRD2, parse_tag_initrd2);
#ifdef CONFIG_OF_FLATTREE
-void __init early_init_dt_setup_initrd_arch(unsigned long start, unsigned long
end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
phys_initrd_start = start;
phys_initrd_size = end - start;
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f497ca7..7047708 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -44,8 +44,7 @@ static unsigned long phys_initrd_size __initdata = 0;
phys_addr_t memstart_addr __read_mostly = 0;
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
phys_initrd_start = start;
phys_initrd_size = end - start;
diff --git a/arch/c6x/kernel/devicetree.c b/arch/c6x/kernel/devicetree.c
index bdb56f0..287d0e6 100644
--- a/arch/c6x/kernel/devicetree.c
+++ b/arch/c6x/kernel/devicetree.c
@@ -33,8 +33,7 @@ void __init early_init_devtree(void *params)
#ifdef CONFIG_BLK_DEV_INITRD
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
initrd_start = (unsigned long)__va(start);
initrd_end = (unsigned long)__va(end);
diff --git a/arch/metag/mm/init.c b/arch/metag/mm/init.c
index d05b845..bdc4811 100644
--- a/arch/metag/mm/init.c
+++ b/arch/metag/mm/init.c
@@ -419,10 +419,9 @@ void free_initrd_mem(unsigned long start, unsigned long
end)
#endif
#ifdef CONFIG_OF_FLATTREE
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
- pr_err("%s(%lx, %lx)\n",
+ pr_err("%s(%llx, %llx)\n",
__func__, start, end);
}
#endif /* CONFIG_OF_FLATTREE */
diff --git a/arch/microblaze/kernel/prom.c
Re: [PATCH RFC 1/3] dt:net:stmmac: Allocate platform data only if its NULL.
On 7/1/2013 1:43 PM, Srinivas KANDAGATLA wrote:
From: Srinivas Kandagatla
In some DT use-cases platform data might be already allocated and passed
via AUXDATA. These are the cases where machine level code populates few
callbacks in the platform data.
This patch adds check and reuses platform_data if its valid, before
allocating a new one.
Ye, we had seen this long time ago and IIRC i prepared the patch
so
Acked-by: Giuseppe Cavallaro
Signed-off-by: Srinivas Kandagatla
---
.../net/ethernet/stmicro/stmmac/stmmac_platform.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 1d3780f..5907920 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -92,8 +92,10 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
if (IS_ERR(addr))
return PTR_ERR(addr);
+ plat_dat = pdev->dev.platform_data;
if (pdev->dev.of_node) {
- plat_dat = devm_kzalloc(&pdev->dev,
+ if (!plat_dat)
+ plat_dat = devm_kzalloc(&pdev->dev,
sizeof(struct plat_stmmacenet_data),
GFP_KERNEL);
if (!plat_dat) {
@@ -106,8 +108,6 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
pr_err("%s: main dt probe failed", __func__);
return ret;
}
- } else {
- plat_dat = pdev->dev.platform_data;
}
/* Custom initialisation (if needed)*/
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC 2/3] dt:net:stmmac: Add support to dwmac version 3.610 and 3.710
On 7/1/2013 1:43 PM, Srinivas KANDAGATLA wrote:
From: Srinivas Kandagatla
This patch adds dt support to dwmac version 3.610 and 3.710 these
versions are integrated in STiH415 and STiH416 ARM A9 SOCs.
To support these IP version, some of the device tree properties are
extended.
Signed-off-by: Srinivas Kandagatla
---
Documentation/devicetree/bindings/net/stmmac.txt |4 +++
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 25
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
b/Documentation/devicetree/bindings/net/stmmac.txt
index 060bbf0..e1ddfcc 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -12,6 +12,10 @@ Required properties:
property
- phy-mode: String, operation mode of the PHY interface.
Supported values are: "mii", "rmii", "gmii", "rgmii".
+- snps,phy-addrphy address to connect to.
+- snps,pbl Programmable Burst Length
+- snps,fixed-burst Program the DMA to use the fixed burst mode
+- snps,mixed-burst Program the DMA to use the mixed burst mode
Optional properties:
- mac-address: 6 bytes, mac address
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 5907920..060758d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -29,17 +29,26 @@
#include "stmmac.h"
#ifdef CONFIG_OF
+
static int stmmac_probe_config_dt(struct platform_device *pdev,
struct plat_stmmacenet_data *plat,
const char **mac)
{
struct device_node *np = pdev->dev.of_node;
+ struct stmmac_dma_cfg *dma_cfg;
if (!np)
return -ENODEV;
*mac = of_get_mac_address(np);
plat->interface = of_get_phy_mode(np);
+
+ plat->bus_id = of_alias_get_id(np, "ethernet");
+ if (plat->bus_id < 0)
+ plat->bus_id = 0;
+
+ of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr);
+
plat->mdio_bus_data = devm_kzalloc(&pdev->dev,
sizeof(struct stmmac_mdio_bus_data),
GFP_KERNEL);
@@ -51,11 +60,25 @@ static int stmmac_probe_config_dt(struct platform_device
*pdev,
*/
if (of_device_is_compatible(np, "st,spear600-gmac") ||
of_device_is_compatible(np, "snps,dwmac-3.70a") ||
+ of_device_is_compatible(np, "snps,dwmac-3.610") ||
of_device_is_compatible(np, "snps,dwmac")) {
plat->has_gmac = 1;
plat->pmt = 1;
}
+ if (of_device_is_compatible(np, "snps,dwmac-3.610") ||
+ of_device_is_compatible(np, "snps,dwmac-3.710")) {
+ plat->enh_desc = 1;
+ plat->bugged_jumbo = 1;
+ plat->force_sf_dma_mode = 1;
+ }
I think some these shouldn't be forced here. Maybe plat->enh_desc could
be set because for new syn mac cores.
Also pmt could not be forced because it is an extra module so it could
happen that a new chip has no PMT block.
+
+ dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*dma_cfg), GFP_KERNEL);
+ plat->dma_cfg = dma_cfg;
+ of_property_read_u32(np, "snps,pbl", &dma_cfg->pbl);
+ dma_cfg->fixed_burst = of_property_read_bool(np, "snps,fixed-burst");
+ dma_cfg->mixed_burst = of_property_read_bool(np, "snps,mixed-burst");
+
return 0;
}
#else
@@ -230,7 +253,9 @@ static const struct dev_pm_ops stmmac_pltfr_pm_ops;
static const struct of_device_id stmmac_dt_ids[] = {
{ .compatible = "st,spear600-gmac"},
+ { .compatible = "snps,dwmac-3.610"},
{ .compatible = "snps,dwmac-3.70a"},
+ { .compatible = "snps,dwmac-3.710"},
{ .compatible = "snps,dwmac"},
{ /* sentinel */ }
};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH RFC 1/3] dt:net:stmmac: Allocate platform data only if its NULL.
On 7/1/2013 1:43 PM, Srinivas KANDAGATLA wrote:
From: Srinivas Kandagatla
In some DT use-cases platform data might be already allocated and passed
via AUXDATA. These are the cases where machine level code populates few
callbacks in the platform data.
This patch adds check and reuses platform_data if its valid, before
allocating a new one.
Yes, we had seen this long time ago and IIRC i prepared the patch
so
Acked-by: Giuseppe Cavallaro
Signed-off-by: Srinivas Kandagatla
---
.../net/ethernet/stmicro/stmmac/stmmac_platform.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 1d3780f..5907920 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -92,8 +92,10 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
if (IS_ERR(addr))
return PTR_ERR(addr);
+ plat_dat = pdev->dev.platform_data;
if (pdev->dev.of_node) {
- plat_dat = devm_kzalloc(&pdev->dev,
+ if (!plat_dat)
+ plat_dat = devm_kzalloc(&pdev->dev,
sizeof(struct plat_stmmacenet_data),
GFP_KERNEL);
if (!plat_dat) {
@@ -106,8 +108,6 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
pr_err("%s: main dt probe failed", __func__);
return ret;
}
- } else {
- plat_dat = pdev->dev.platform_data;
}
/* Custom initialisation (if needed)*/
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: binding for nvec mfd device
On 06/29/2013 10:22 AM, Marc Dietrich wrote:
> On Friday 28 June 2013 09:13:38 Stephen Warren wrote:
>> On 06/27/2013 12:26 PM, Marc Dietrich wrote:
...
>>> I'm puzzling for some time now to find a binding for a mfd device. So
>>> let's
>>> start with something I think I have learned already, let's describe the
>>> hardware.
...
>> I would eventually like to do the following:
>>
>> * Have a node that represents the I2C slave controller HW module in Tegra.
>>
>> * Have a node (or nodes) (perhaps a child node of that) which represents
>> the protocol that "binds" to the slave controller. This would have its
>> own compatible value that describes which protocol to instantiate.
>>
>> This will separate the driver for the I2C slave HW from the driver for
>> the protocol, so that you could even run the same protocol with a
>> different I2C slave device if needed.
>
> I agree with you that the slave driver should be separated from the protocol
> (which itself can also be separated into e.g. smbus and nvec layers). But
> that's more like a long term goal which we cannot handle so quickly. For this
> to work, you probably also need a kernel api for i2c slaves which many people
> failed to introduce in the past already. The NVIDIA downstream kernel has
> something like this already (are there any clients?), but unfortunately no
> smbus protocol support yet.
>
> So keeping this in mind, the binding above already looks ok, even if it is
> named "nvec" instead of e.g. "i2c-slave" for now.
Well, the DT binding is supposed to be describing the HW (or at least
the SW-visible aspects of the HW), so we should not be designing the
binding to suit a particular SW/driver structure. Instead, the binding
should describe the HW, and the SW should be written to work with the
binding.
Put another way, the binding is something that shouldn't change even if
the SW/driver structure does.
So, if we're coming up with a final binding to correctly represent nvec,
we should split the I2C slave, protocol, protocol clients all out, since
that's the best representation of the HW and protocol.
...
>>> One question is now how to instantiate the mfd children from this. I see
>>> three>
>>> different methods used in different drivers:
>>> a) just add a "compatible =" property to the child nodes and a
>>>
>>> "simple-bus" property to the the driver
>>
>> (or instead of simple-bus, have the top-level node's probe() do the
>> following at the end:
>>
>> of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
>>
>> That's what sounds/soc/tegra/tegra30_ahub.c does.
>
> "simple-bus" and maybe also of_platform_populate are only favored if there is
> a real bus, AFAIU, which isn't the here (and maybe also not for other mfds).
I don't think that restriction is generally true. I've certainly seen
seasoned DT experts state that *not* breaking things up into individual
components has almost always turned out to be a mistake.
Besides, the nvec protocol really is a bus, even a physical one in some
ways. It multiplexes access to a variety of endpoints (keyboard, GPIOs)
over a communication channel (nvec protocol, over a physical I2C channel).
>> I prefer either:
...
>> 2) Your option a. I believe if we're going to break down the MFD device
>> into chunks, the way we do it should mirror existing DT techniques as
>> closely as possible, and using nodes with compatible values to represent
>> the child devices seems most consistent with existing techniques.
>
> Thinking about what you said at the beginning, I think it's best not to use
> any sub-nodes at all, but give all children a node of their own (standalone
> driver) with compatible properties and a link property to the device
> responsible for the communications (nvec or i2c-slave in our case), similar
> to
> the backlight property for panels:
>
> root {
>
> nvec: nvec {
> compatible = "nvidia,nvec";
> ...
> };
>
> keyboard {
> compatible = "nvidia,nvec-keyboard";
> nvec = <&nvec>;
> };
>
> };
So here, the keyboard node is using nvec as the communication transport
for all its data. That *is* a bus, and devices on buses are typically
child nodes of the bus itself; take a look at the I2C or SPI master
bindings. The only exception to this I can think off quickly is the I2C
mux bindings, and that's because the control of the muxing isn't
necessarily part of the data path being muxed.
> I'm not sure if we can still use the function exports from the nvec or if we
> need to add some "ops" to the nvec struct. Maybe the latter would be the
> better solution. I'm also wondering if we can guaranty that the nvec is
> loaded
> before any children and that the children are unloaded before the nvec core
> driver.
The driver for the keyboard node above would have to convert the phandle
in the nvec property to some kind of nvec device/d
[PATCH v3 13/13] ARM: dts: Add MIPI PHY node to exynos4.dtsi
Add PHY provider node for the MIPI CSIS and MIPI DSIM PHYs.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
Acked-by: Felipe Balbi
---
arch/arm/boot/dts/exynos4.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 752624f..e27eba8 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -49,6 +49,12 @@
reg = <0x1000 0x100>;
};
+ mipi_phy: video-phy@10020710 {
+ compatible = "samsung,s5pv210-mipi-video-phy";
+ reg = <0x10020710 8>;
+ #phy-cells = <1>;
+ };
+
pd_mfc: mfc-power-domain@10023C40 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023C40 0x20>;
@@ -157,6 +163,8 @@
clock-names = "csis", "sclk_csis";
bus-width = <4>;
samsung,power-domain = <&pd_cam>;
+ phys = <&mipi_phy 0>;
+ phy-names = "csis";
status = "disabled";
};
@@ -168,6 +176,8 @@
clock-names = "csis", "sclk_csis";
bus-width = <2>;
samsung,power-domain = <&pd_cam>;
+ phys = <&mipi_phy 2>;
+ phy-names = "csis";
status = "disabled";
};
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 11/13] ARM: dts: Add Exynos4210 SoC camera port pinctrl nodes
From: Andrzej Hajda
Add pinctrl nodes for the camera parallel port CAM_A data bus
and the CAM_A_CLKOUT clock output pin.
Signed-off-by: Andrzej Hajda
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
index 553bcea..a7c2128 100644
--- a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
@@ -797,6 +797,29 @@
samsung,pin-pud = <0>;
samsung,pin-drv = <0>;
};
+
+ cam_port_a_io: cam-port-a-io {
+ samsung,pins = "gpj0-0", "gpj0-1", "gpj0-2", "gpj0-3",
+ "gpj0-4", "gpj0-5", "gpj0-6", "gpj0-7",
+ "gpj1-0", "gpj1-1", "gpj1-2", "gpj1-4";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ cam_port_a_clk_active: cam-port-a-clk-active {
+ samsung,pins = "gpj1-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 = "gpj1-3";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <1>;
+ samsung,pin-drv = <0>;
+ };
};
pinctrl@0386 {
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 12/13] ARM: dts: Add S5K5BA sensor regulator definitions for Trats board
From: Andrzej Hajda
Add MAX8998 LDO12 and fixed voltage regulator nodes. While at it,
all fixed voltage regulator nodes are grouped in a 'regulators' node.
Signed-off-by: Andrzej Hajda
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4210-trats.dts | 80 +---
1 file changed, 64 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index 6b1568e..f62e299 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -30,13 +30,64 @@
bootargs = "console=ttySAC2,115200N8 root=/dev/mmcblk0p5
rootwait earlyprintk panic=5";
};
- vemmc_reg: voltage-regulator@0 {
- compatible = "regulator-fixed";
- regulator-name = "VMEM_VDD_2.8V";
- regulator-min-microvolt = <280>;
- regulator-max-microvolt = <280>;
- gpio = <&gpk0 2 0>;
- enable-active-high;
+ regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vemmc_reg: regulator@0 {
+ compatible = "regulator-fixed";
+ regulator-name = "VMEM_VDD_2.8V";
+ regulator-min-microvolt = <280>;
+ regulator-max-microvolt = <280>;
+ gpio = <&gpk0 2 0>;
+ enable-active-high;
+ };
+
+ tsp_reg: regulator@1 {
+ compatible = "regulator-fixed";
+ regulator-name = "TSP_FIXED_VOLTAGES";
+ regulator-min-microvolt = <280>;
+ regulator-max-microvolt = <280>;
+ gpio = <&gpl0 3 0>;
+ enable-active-high;
+ };
+
+ cam_af_28v_reg: regulator@2 {
+ compatible = "regulator-fixed";
+ regulator-name = "8M_AF_2.8V_EN";
+ regulator-min-microvolt = <280>;
+ regulator-max-microvolt = <280>;
+ gpio = <&gpk1 1 0>;
+ enable-active-high;
+ };
+
+ cam_io_en_reg: regulator@3 {
+ compatible = "regulator-fixed";
+ regulator-name = "CAM_IO_EN";
+ regulator-min-microvolt = <280>;
+ regulator-max-microvolt = <280>;
+ gpio = <&gpe2 1 0>;
+ enable-active-high;
+ };
+
+ cam_io_12v_reg: regulator@4 {
+ compatible = "regulator-fixed";
+ regulator-name = "8M_1.2V_EN";
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ gpio = <&gpe2 5 0>;
+ enable-active-high;
+ };
+
+ vt_core_15v_reg: regulator@5 {
+ compatible = "regulator-fixed";
+ regulator-name = "VT_CORE_1.5V";
+ regulator-min-microvolt = <150>;
+ regulator-max-microvolt = <150>;
+ gpio = <&gpe2 2 0>;
+ enable-active-high;
+ };
};
sdhci_emmc: sdhci@1251 {
@@ -97,15 +148,6 @@
};
};
- tsp_reg: voltage-regulator {
- compatible = "regulator-fixed";
- regulator-name = "TSP_FIXED_VOLTAGES";
- regulator-min-microvolt = <280>;
- regulator-max-microvolt = <280>;
- gpio = <&gpl0 3 0>;
- enable-active-high;
- };
-
i2c@1389 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-slave-addr = <0x10>;
@@ -218,6 +260,12 @@
regulator-always-on;
};
+ vtcam_reg: LDO12 {
+regulator-name = "VT_CAM_1.8V";
+regulator-min-microvolt = <180>;
+regulator-max-microvolt = <180>;
+ };
+
vcclcd_reg: LDO13 {
regulator-name = "VCC_3.3V_LCD";
regulator-min-microvolt = <330>;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 10/13] ARM: dts: Add FIMC nodes for Exynos4210 Trats board
Enable FIMC devices on the Trats board. This allows using the
device in memory-to-memory mode only. The camera port pinctrl
property is now empty and will be updated while support for the
camera sensors is added.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4210-trats.dts | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index 94eebff..6b1568e 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -301,4 +301,27 @@
clock-frequency = <2400>;
};
};
+
+ camera {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <>;
+
+ fimc_0: fimc@1180 {
+ status = "okay";
+ };
+
+ fimc_1: fimc@1181 {
+ status = "okay";
+ };
+
+ fimc_2: fimc@1182 {
+ status = "okay";
+ };
+
+ fimc_3: fimc@1183 {
+ status = "okay";
+ };
+ };
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 09/13] ARM: dts: Add camera device nodes for Exynos4210 SoCs
Add common camera node and detailed properties for
the Exynos4210 FIMC devices.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4210.dtsi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index b7f358a..ef8c2a5 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -125,4 +125,34 @@
clock-names = "sclk_fimg2d", "fimg2d";
status = "disabled";
};
+
+ camera {
+ clocks = <&clock 132>, <&clock 133>, <&clock 351>, <&clock 352>;
+ clock-names = "sclk_cam0", "sclk_cam1", "pxl_async0",
"pxl_async1";
+
+ fimc_0: fimc@1180 {
+ samsung,pix-limits = <4224 8192 1920 4224>;
+ samsung,mainscaler-ext;
+ samsung,cam-if;
+ };
+
+ fimc_1: fimc@1181 {
+ samsung,pix-limits = <4224 8192 1920 4224>;
+ samsung,mainscaler-ext;
+ samsung,cam-if;
+ };
+
+ fimc_2: fimc@1182 {
+ samsung,pix-limits = <4224 8192 1920 4224>;
+ samsung,mainscaler-ext;
+ samsung,lcd-wb;
+ };
+
+ fimc_3: fimc@1183 {
+ samsung,pix-limits = <1920 8192 1366 1920>;
+ samsung,rotators = <0>;
+ samsung,mainscaler-ext;
+ samsung,lcd-wb;
+ };
+ };
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 08/13] ARM: dts: Add camera device nodes for Exynos4412 TRATS2 board
This patch enables the front camera using the internal
camera ISP (FIMC-IS).
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4412-trats2.dts | 91 +++
1 file changed, 91 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index b9de3b5..e9fb3de 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -62,6 +62,15 @@
enable-active-high;
};
+ cam_io_reg: voltage-regulator@3 {
+ compatible = "regulator-fixed";
+ regulator-name = "CAM_SENSOR_A";
+ regulator-min-microvolt = <280>;
+ regulator-max-microvolt = <280>;
+ gpio = <&gpm0 2 0>;
+ enable-active-high;
+ };
+
/* More to come */
};
@@ -472,4 +481,86 @@
gpios = <&gpj0 7 0>;
};
};
+
+ camera {
+ pinctrl-names = "default";
+ pinctrl-0 = <&cam_port_b_clk_active>;
+ status = "okay";
+
+ fimc_0: fimc@1180 {
+ clock-frequency = <16000>;
+ status = "okay";
+ };
+
+ fimc_1: fimc@1181 {
+ clock-frequency = <16000>;
+ status = "okay";
+ };
+
+ fimc_2: fimc@1182 {
+ clock-frequency = <16000>;
+ status = "okay";
+ };
+
+ fimc_3: fimc@1183 {
+ clock-frequency = <16000>;
+ status = "okay";
+ };
+
+ csis_1: csis@1189 {
+ vddcore-supply = <&ldo8_reg>;
+ vddio-supply = <&ldo10_reg>;
+ clock-frequency = <16000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ /* Camera D (4) MIPI CSI-2 (CSIS1) */
+ port@4 {
+ reg = <4>;
+ csis1_ep: endpoint {
+ remote-endpoint = <&is_s5k6a3_ep>;
+ data-lanes = <1>;
+ samsung,csis-hs-settle = <18>;
+ samsung,csis-wclk;
+ };
+ };
+ };
+
+ fimc_lite_0: fimc-lite@1239 {
+ status = "okay";
+ };
+
+ fimc_lite_1: fimc-lite@123A {
+ status = "okay";
+ };
+
+ fimc-is@1200 {
+ pinctrl-0 = <&fimc_is_uart>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ i2c1_isp: i2c-isp@1214 {
+ pinctrl-0 = <&fimc_is_i2c1>;
+ pinctrl-names = "default";
+
+ s5k6a3@10 {
+ compatible = "samsung,s5k6a3";
+ reg = <0x10>;
+ svdda-supply = <&cam_io_reg>;
+ svddio-supply = <&ldo19_reg>;
+ clock-frequency = <2400>;
+ samsung,camclk-out = <1>;
+ gpios = <&gpm1 6 0>;
+
+ port {
+ is_s5k6a3_ep: endpoint {
+ remote-endpoint =
<&csis1_ep>;
+ data-lanes = <1>;
+ };
+ };
+ };
+ };
+ };
+ };
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 07/13] ARM: dts: Add AK8975 device node for Exynos4412 TRATS2 board
From: Jacek Anaszewski
This patch adds AK8975 magnetometer node and corresponding
i2c-gpio bus node for TRATS2 board.
Signed-off-by: Jacek Anaszewski
Signed-off-by: Kyungmin Park
Signed-off-by: Sylwester Nawrocki
---
arch/arm/boot/dts/exynos4412-trats2.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 056b835..b9de3b5 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -19,6 +19,10 @@
model = "Samsung Trats 2 based on Exynos4412";
compatible = "samsung,trats2", "samsung,exynos4412";
+ aliases {
+ i2c8 = &i2c_ak8975;
+ };
+
memory {
reg = <0x4000 0x4000>;
};
@@ -453,4 +457,19 @@
serial@1383 {
status = "okay";
};
+
+ i2c_ak8975: i2c-gpio@0 {
+ compatible = "i2c-gpio";
+ gpios = <&gpy2 4 0>, <&gpy2 5 0>;
+ i2c-gpio,delay-us = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ ak8975@0c {
+ compatible = "asahi-kasei,ak8975";
+ reg = <0x0c>;
+ gpios = <&gpj0 7 0>;
+ };
+ };
};
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 05/13] ARM: dts: Add camera subsystem device nodes to exynos4.dtsi
This patch adds the FIMC and MIPI CSIS device nodes common to the Exynos4
SoC series.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Changes since v2:
- added fimc/csis clock properties common for exynos4210 and exynos4x12
---
arch/arm/boot/dts/exynos4.dtsi | 80
1 file changed, 80 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index bce2254..752624f 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -36,6 +36,12 @@
i2c5 = &i2c_5;
i2c6 = &i2c_6;
i2c7 = &i2c_7;
+ csis0 = &csis_0;
+ csis1 = &csis_1;
+ fimc0 = &fimc_0;
+ fimc1 = &fimc_1;
+ fimc2 = &fimc_2;
+ fimc3 = &fimc_3;
};
chipid@1000 {
@@ -92,6 +98,80 @@
reg = <0x1001 0x400>;
};
+ camera {
+ compatible = "samsung,fimc", "simple-bus";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ fimc_0: fimc@1180 {
+ compatible = "samsung,exynos4210-fimc";
+ reg = <0x1180 0x1000>;
+ interrupts = <0 84 0>;
+ clocks = <&clock 256>, <&clock 128>;
+ clock-names = "fimc", "sclk_fimc";
+ samsung,power-domain = <&pd_cam>;
+ samsung,sysreg = <&sys_reg>;
+ status = "disabled";
+ };
+
+ fimc_1: fimc@1181 {
+ compatible = "samsung,exynos4210-fimc";
+ reg = <0x1181 0x1000>;
+ interrupts = <0 85 0>;
+ clocks = <&clock 257>, <&clock 129>;
+ clock-names = "fimc", "sclk_fimc";
+ samsung,power-domain = <&pd_cam>;
+ samsung,sysreg = <&sys_reg>;
+ status = "disabled";
+ };
+
+ fimc_2: fimc@1182 {
+ compatible = "samsung,exynos4210-fimc";
+ reg = <0x1182 0x1000>;
+ interrupts = <0 86 0>;
+ clocks = <&clock 258>, <&clock 130>;
+ clock-names = "fimc", "sclk_fimc";
+ samsung,power-domain = <&pd_cam>;
+ samsung,sysreg = <&sys_reg>;
+ status = "disabled";
+ };
+
+ fimc_3: fimc@1183 {
+ compatible = "samsung,exynos4210-fimc";
+ reg = <0x1183 0x1000>;
+ interrupts = <0 87 0>;
+ clocks = <&clock 259>, <&clock 131>;
+ clock-names = "fimc", "sclk_fimc";
+ samsung,power-domain = <&pd_cam>;
+ samsung,sysreg = <&sys_reg>;
+ status = "disabled";
+ };
+
+ csis_0: csis@1188 {
+ compatible = "samsung,exynos4210-csis";
+ reg = <0x1188 0x4000>;
+ interrupts = <0 78 0>;
+ clocks = <&clock 260>, <&clock 134>;
+ clock-names = "csis", "sclk_csis";
+ bus-width = <4>;
+ samsung,power-domain = <&pd_cam>;
+ status = "disabled";
+ };
+
+ csis_1: csis@1189 {
+ compatible = "samsung,exynos4210-csis";
+ reg = <0x1189 0x4000>;
+ interrupts = <0 80 0>;
+ clocks = <&clock 261>, <&clock 135>;
+ clock-names = "csis", "sclk_csis";
+ bus-width = <2>;
+ samsung,power-domain = <&pd_cam>;
+ status = "disabled";
+ };
+ };
+
watchdog@1006 {
compatible = "samsung,s3c2410-wdt";
reg = <0x1006 0x100>;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 06/13] ARM: dts: Add camera subsystem nodes to exynos4x12.dtsi
Add common camera node and Exynos4212/4412 specific nodes for
FIMC, MIPI-CSIS, FIMC-LITE and FIMC-IS devices.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Changes since v2:
- fixed typo in exynos4x12 i2c_isp node reg property,
- removed the clock properties which are now moved to exynos4.dtsi,
"mux" and "parent" clock entries are dropped.
---
arch/arm/boot/dts/exynos4x12.dtsi | 98 +
1 file changed, 98 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 0e24d85..954628c 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -26,6 +26,8 @@
pinctrl1 = &pinctrl_1;
pinctrl2 = &pinctrl_2;
pinctrl3 = &pinctrl_3;
+ fimc-lite0 = &fimc_lite_0;
+ fimc-lite1 = &fimc_lite_1;
};
pd_isp: isp-power-domain@10023CA0 {
@@ -78,4 +80,100 @@
clock-names = "sclk_fimg2d", "fimg2d";
status = "disabled";
};
+
+ camera {
+ clocks = <&clock 132>, <&clock 133>, <&clock 351>, <&clock 352>;
+ clock-names = "sclk_cam0", "sclk_cam1", "pxl_async0",
"pxl_async1";
+
+ fimc_0: fimc@1180 {
+ compatible = "samsung,exynos4212-fimc";
+ samsung,pix-limits = <4224 8192 1920 4224>;
+ samsung,mainscaler-ext;
+ samsung,isp-wb;
+ samsung,cam-if;
+ };
+
+ fimc_1: fimc@1181 {
+ compatible = "samsung,exynos4212-fimc";
+ samsung,pix-limits = <4224 8192 1920 4224>;
+ samsung,mainscaler-ext;
+ samsung,isp-wb;
+ samsung,cam-if;
+ };
+
+ fimc_2: fimc@1182 {
+ compatible = "samsung,exynos4212-fimc";
+ samsung,pix-limits = <4224 8192 1920 4224>;
+ samsung,mainscaler-ext;
+ samsung,isp-wb;
+ samsung,lcd-wb;
+ samsung,cam-if;
+ };
+
+ fimc_3: fimc@1183 {
+ compatible = "samsung,exynos4212-fimc";
+ samsung,pix-limits = <1920 8192 1366 1920>;
+ samsung,rotators = <0>;
+ samsung,mainscaler-ext;
+ samsung,isp-wb;
+ samsung,lcd-wb;
+ };
+
+ fimc_lite_0: fimc-lite@1239 {
+ compatible = "samsung,exynos4212-fimc-lite";
+ reg = <0x1239 0x1000>;
+ interrupts = <0 105 0>;
+ samsung,power-domain = <&pd_isp>;
+ clocks = <&clock 353>;
+ clock-names = "flite";
+ status = "disabled";
+ };
+
+ fimc_lite_1: fimc-lite@123A {
+ compatible = "samsung,exynos4212-fimc-lite";
+ reg = <0x123A 0x1000>;
+ interrupts = <0 106 0>;
+ samsung,power-domain = <&pd_isp>;
+ clocks = <&clock 354>;
+ clock-names = "flite";
+ status = "disabled";
+ };
+
+ fimc_is: fimc-is@1200 {
+ compatible = "samsung,exynos4212-fimc-is", "simple-bus";
+ reg = <0x1200 0x26>;
+ interrupts = <0 90 0>, <0 95 0>;
+ samsung,power-domain = <&pd_isp>;
+ clocks = <&clock 353>, <&clock 354>, <&clock 355>,
+ <&clock 356>, <&clock 17>, <&clock 357>,
+ <&clock 358>, <&clock 359>, <&clock 360>,
+ <&clock 450>,<&clock 451>, <&clock 452>,
+ <&clock 453>, <&clock 176>, <&clock 13>,
+ <&clock 454>, <&clock 395>, <&clock 455>;
+ clock-names = "lite0", "lite1", "ppmuispx",
+ "ppmuispmx", "mpll", "isp",
+ "drc", "fd", "mcuisp",
+ "ispdiv0", "ispdiv1", "mcuispdiv0",
+ "mcuispdiv1", "uart", "aclk200",
+ "div_aclk200", "aclk400mcuisp",
+ "div_aclk400mcuisp";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ status = "disabled";
+
+ pmu {
+ reg = <0x1002 0x3000>;
+
[PATCH v3 04/13] ARM: dts: Use generic DMA bindings for Exynos4 SPI devices
The Exynos4 SPI controller has migrated to the generic DMA bindings since commit b5be04d35dbb2e00 "spi: s3c64xx: Modify SPI driver to use generic DMA DT support". Use the generic bindings to specify the corresponding DMA to make the SPI usable again on Exynos4x12 SoCs. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- Changes since v2: - edited commit description. --- arch/arm/boot/dts/exynos4.dtsi | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi index 3f94fe8..bce2254 100644 --- a/arch/arm/boot/dts/exynos4.dtsi +++ b/arch/arm/boot/dts/exynos4.dtsi @@ -297,8 +297,8 @@ compatible = "samsung,exynos4210-spi"; reg = <0x1392 0x100>; interrupts = <0 66 0>; - tx-dma-channel = <&pdma0 7>; /* preliminary */ - rx-dma-channel = <&pdma0 6>; /* preliminary */ + dmas = <&pdma0 7>, <&pdma0 6>; + dma-names = "tx", "rx"; #address-cells = <1>; #size-cells = <0>; clocks = <&clock 327>, <&clock 159>; @@ -312,8 +312,8 @@ compatible = "samsung,exynos4210-spi"; reg = <0x1393 0x100>; interrupts = <0 67 0>; - tx-dma-channel = <&pdma1 7>; /* preliminary */ - rx-dma-channel = <&pdma1 6>; /* preliminary */ + dmas = <&pdma1 7>, <&pdma1 6>; + dma-names = "tx", "rx"; #address-cells = <1>; #size-cells = <0>; clocks = <&clock 328>, <&clock 160>; @@ -327,8 +327,8 @@ compatible = "samsung,exynos4210-spi"; reg = <0x1394 0x100>; interrupts = <0 68 0>; - tx-dma-channel = <&pdma0 9>; /* preliminary */ - rx-dma-channel = <&pdma0 8>; /* preliminary */ + dmas = <&pdma0 9>, <&pdma0 8>; + dma-names = "tx", "rx"; #address-cells = <1>; #size-cells = <0>; clocks = <&clock 329>, <&clock 161>; -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 03/13] ARM: dts: Add ISP power domain node for Exynos4x12
The ISP power domain is a common power domain for FIMC-LITE
and FIMC-IS (camera ISP) devices.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4x12.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 01da194..0e24d85 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -28,6 +28,11 @@
pinctrl3 = &pinctrl_3;
};
+ pd_isp: isp-power-domain@10023CA0 {
+ compatible = "samsung,exynos4210-pd";
+ reg = <0x10023CA0 0x20>;
+ };
+
clock: clock-controller@0x1003 {
compatible = "samsung,exynos4412-clock";
reg = <0x1003 0x2>;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 02/13] ARM: dts: Add pinctrl entries for Exynos4x12 FIMC-IS peripherals
Add pinctrl nodes for the ISP I2C0, ISP I2C1 and ISP UART devices.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
index 55ff73b..99b26df 100644
--- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
@@ -848,6 +848,27 @@
samsung,pin-pud = <0>;
samsung,pin-drv = <0>;
};
+
+ fimc_is_i2c0: fimc-is-i2c0 {
+ samsung,pins = "gpm4-0", "gpm4-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ fimc_is_i2c1: fimc-is-i2c1 {
+ samsung,pins = "gpm4-2", "gpm4-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ fimc_is_uart: fimc-is-uart {
+ samsung,pins = "gpm3-5", "gpm3-7";
+ samsung,pin-function = <3>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
};
pinctrl@0386 {
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 01/13] ARM: dts: Correct camera pinctrl nodes for Exynos4x12 SoCs
Add separate nodes for the CAMCLK pin and turn off pull-up on camera
ports A, B. The video bus pins and the clock output (CAMCLK) pin need
separate nodes since full camera port is not used in some configurations,
e.g. for MIPI CSI-2 bus only CAMCLK is required and data/clock signal
use separate dedicated pins.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 40 -
1 file changed, 33 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
index 704290f..55ff73b 100644
--- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
@@ -401,13 +401,26 @@
samsung,pin-drv = <0>;
};
- cam_port_a: cam-port-a {
+ cam_port_a_io: cam-port-a-io {
samsung,pins = "gpj0-0", "gpj0-1", "gpj0-2", "gpj0-3",
"gpj0-4", "gpj0-5", "gpj0-6", "gpj0-7",
- "gpj1-0", "gpj1-1", "gpj1-2", "gpj1-3",
- "gpj1-4";
+ "gpj1-0", "gpj1-1", "gpj1-2", "gpj1-4";
samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
+ cam_port_a_clk_active: cam-port-a-clk-active {
+ samsung,pins = "gpj1-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 = "gpj1-3";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <1>;
samsung,pin-drv = <0>;
};
};
@@ -778,16 +791,29 @@
samsung,pin-drv = <3>;
};
- cam_port_b: cam-port-b {
+ cam_port_b_io: cam-port-b-io {
samsung,pins = "gpm0-0", "gpm0-1", "gpm0-2", "gpm0-3",
"gpm0-4", "gpm0-5", "gpm0-6", "gpm0-7",
- "gpm1-0", "gpm1-1", "gpm2-0", "gpm2-1",
- "gpm2-2";
+ "gpm1-0", "gpm1-1", "gpm2-0", "gpm2-1";
samsung,pin-function = <3>;
samsung,pin-pud = <3>;
samsung,pin-drv = <0>;
};
+ cam_port_b_clk_active: cam-port-b-clk-active {
+ samsung,pins = "gpm2-2";
+ samsung,pin-function = <3>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <3>;
+ };
+
+ cam_port_b_clk_idle: cam-port-b-clk-idle {
+ samsung,pins = "gpm2-2";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <1>;
+ samsung,pin-drv = <0>;
+ };
+
eint0: ext-int0 {
samsung,pins = "gpx0-0";
samsung,pin-function = <0xf>;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 00/13] ARM: dts: Add camera and magnetometer support for TRATS(2) board
This patch series includes some fixes and extensions to the Exynos dts
files to add the camera and magnetometer sensor support for the TRATS
and TRATS2 board. It depends on a patch from Tomasz adding initial
TRATS2 board dts file [1].
Comparing to the previous version of this patch set I've added a few
more patches, for the Exynos4210 based TRATS board and a patch adding
MIPI CSIS/DSIM PHY provider nodes and related properties to the PHY
consumer nodes.
This series has been tested with the S5K6A3/FIMC-IS and S5K5BAFX
(front facing) cameras on top of next-20130627 tag. It can be found
also at:
http://git.linuxtv.org/snawrocki/samsung.git/next-20130627-dts-trats-v3
Detailed changes since v2 are listed in each patch.
Changes since v1:
- enabled pull down in cam-port-{a, b}-clk-idle nodes (1/8)
- added node alias for i2c-gpio@0 I2C controller node (7/8).
[1] http://www.spinics.net/lists/arm-kernel/msg253184.html
Andrzej Hajda (2):
ARM: dts: Add Exynos4210 SoC camera port pinctrl nodes
ARM: dts: Add S5K5BA sensor regulator definitions for Trats board
Jacek Anaszewski (1):
ARM: dts: Add AK8975 device node for Exynos4412 TRATS2 board
Sylwester Nawrocki (10):
ARM: dts: Correct camera pinctrl nodes for Exynos4x12 SoCs
ARM: dts: Add pinctrl entries for Exynos4x12 FIMC-IS peripherals
ARM: dts: Add ISP power domain node for Exynos4x12
ARM: dts: Use generic DMA bindings for Exynos4 SPI devices
ARM: dts: Add camera subsystem device nodes to exynos4.dtsi
ARM: dts: Add camera subsystem nodes to exynos4x12.dtsi
ARM: dts: Add camera device nodes for Exynos4412 TRATS2 board
ARM: dts: Add camera device nodes for Exynos4210 SoCs
ARM: dts: Add FIMC nodes for Exynos4210 Trats board
ARM: dts: Add MIPI PHY node to exynos4.dtsi
arch/arm/boot/dts/exynos4.dtsi| 102 --
arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 23 ++
arch/arm/boot/dts/exynos4210-trats.dts| 103 ++-
arch/arm/boot/dts/exynos4210.dtsi | 30
arch/arm/boot/dts/exynos4412-trats2.dts | 110 +
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 61 ++--
arch/arm/boot/dts/exynos4x12.dtsi | 103 +++
7 files changed, 503 insertions(+), 29 deletions(-)
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of: Specify initrd location using 64-bit
On Monday 01 July 2013 03:59 AM, Geert Uytterhoeven wrote: > On Mon, Jul 1, 2013 at 9:48 AM, Sebastian Andrzej Siewior > wrote: >> On 06/29/2013 01:43 AM, Santosh Shilimkar wrote: >>> Apart from waste of 32bit, what is the other concern you >>> have ? >> >> You pass a u64 as a physical address which is represented in other >> parts of the kernel (for a good reason) by phys_addr_t. >> >>> I really want to converge on this patch because it >>> has been a open ended discussion for quite some time. Does >>> that really break any thing on x86 or your concern is more >>> from semantics of the physical address. >> You want to have your code in so you can continue with your work, that >> is okay. The other two arguments why u64 here is a good thing was "due >> to what I said earlier" and "+1" and I don't have the time to look >> that up. >> >> There should be no problems on x86 if this goes in as it is now. >> >> But think about this: What happens if you boot your ARM device without >> PAE and your initrd is in the upper region? If you are lucky the kernel >> looks at a different place where it also has a read permission, notices >> nothing sane is there, writes a message and continues. And if it is not >> allowed to read? It is clearly the user's fault for booting a non-PAE >> kernel. > > That's actual the original reason: DT has it as 64 bit, and passes it to a > 32 bit kernel when running in 32 bit mode without PAE. > Thanks all for comments and useful discussion. I will resubmit the patch with update to fix the printk warnings reported by Vineet and James post the $subject change. Am assuming the patch will go via Grant Likely's tree. Regards, Santosh ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
On Fri, 2013-06-28 at 16:21 +0300, Luciano Coelho wrote:
> On Fri, 2013-06-28 at 15:18 +0300, Felipe Balbi wrote:
> > On Fri, Jun 28, 2013 at 03:13:52PM +0300, Luciano Coelho wrote:
> > > On Fri, 2013-06-28 at 14:41 +0300, Felipe Balbi wrote:
> > > > On Fri, Jun 28, 2013 at 02:22:11PM +0300, Luciano Coelho wrote:
> > > > > On Fri, 2013-06-28 at 13:31 +0300, Luciano Coelho wrote:
> > > > > > (fixed Mike's address)
> > > > > >
> > > > > > On Fri, 2013-06-28 at 11:21 +0100, Mark Rutland wrote:
> > > > > > > On Fri, Jun 28, 2013 at 10:53:35AM +0100, Luciano Coelho wrote:
> > > > > > > > On Fri, 2013-06-28 at 10:38 +0100, Mark Rutland wrote:
> > > > > > > > > On Tue, Jun 25, 2013 at 09:35:30AM +0100, Luciano Coelho
> > > > > > > > > wrote:
> > > > > > > > > > +Optional properties:
> > > > > > > > > > +
> > > > > > > > > > +
> > > > > > > > > > +- refclock: the internal WLAN reference clock frequency
> > > > > > > > > > (required for
> > > > > > > > > > + WiLink6 and WiLink7; not used for WiLink8). Must be one
> > > > > > > > > > of the
> > > > > > > > > > + following:
> > > > > > > > > > + 0 = 19.2 MHz
> > > > > > > > > > + 1 = 26.0 MHz
> > > > > > > > > > + 2 = 38.4 MHz
> > > > > > > > > > + 3 = 52.0 MHz
> > > > > > > > > > + 4 = 38.4 MHz, XTAL
> > > > > > > > > > + 5 = 26.0 MHz, XTAL
> > > > > > > > > > +
> > > > > > > > > > +- tcxoclock: the internal WLAN TCXO clock frequency
> > > > > > > > > > (required for
> > > > > > > > > > + WiLink7 not used for WiLink6 and WiLink8). Must be one
> > > > > > > > > > of the
> > > > > > > > > > + following:
> > > > > > > > > > + 0 = 19.200 MHz
> > > > > > > > > > + 1 = 26.000 MHz
> > > > > > > > > > + 2 = 38.400 MHz
> > > > > > > > > > + 3 = 52.000 MHz
> > > > > > > > > > + 4 = 16.368 MHz
> > > > > > > > > > + 5 = 32.736 MHz
> > > > > > > > > > + 6 = 16.800 MHz
> > > > > > > > > > + 7 = 33.600 MHz
> > > > > > > > >
> > > > > > > > > This looks suspiciously like what we have the common clock
> > > > > > > > > bindings for:
> > > > > > > > >
> > > > > > > > > refclk {
> > > > > > > > > compatible = "fixed-clock";
> > > > > > > > > #clock-cells = <0>;
> > > > > > > > > clock-frequency = <1920>;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > wilink {
> > > > > > > > > compatible = "ti,wilink7";
> > > > > > > > > interrupt-parent = <&some_interrupt_controller>;
> > > > > > > > > interrupts = <0 1 1>;
> > > > > > > > > clocks = <&refclk>, <&refclk>;
> > > > > > > > > clock-names = "refclk", "txoclk";
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > Could you not use them?
> > > > > > > >
> > > > > > > > Hmmm... this actually does look good. But these are internal
> > > > > > > > clocks in
> > > > > > > > the modules, they cannot be accessed from outside. Does it
> > > > > > > > make sense
> > > > > > > > to register them with the clock framework?
> > > > > > >
> > > > > > > Given we already have a common way of describing clocks, I think
> > > > > > > it
> > > > > > > makes sense to use it -- people already understand the common
> > > > > > > bindings,
> > > > > > > and it's less code to add add to the kernel. I don't think the
> > > > > > > fact
> > > > > > > these clocks are internal should prevent us from describing them
> > > > > > > as we
> > > > > > > would an external clock.
> > > > > >
> > > > > > Yes, I agree with you. Thanks for the suggestion! I think it will
> > > > > > look
> > > > > > much better. And now that I dug a bit more into the code, I can see
> > > > > > that there are only structs being populated, so there shouldn't be
> > > > > > any
> > > > > > other side-effects.
> > > > >
> > > > > Hmmm, one thing that escaped me. Besides the frequency, I also need a
> > > > > boolean that tells if the clock is XTAL or not. I can't figure out
> > > > > how
> > > > > to pass this if I use the generic clock framework. Any suggestions?
> > > >
> > > > Could you use clock-output-names for that ?
> > > >
> > > > XTAL clock:
> > > >
> > > > refclk {
> > > > compatible = "fixed-clock";
> > > > #clock cells = <0>;
> > > > clock-frequency = <1920>;
> > > > clock-output-names = "xtal";
> > > > };
> > > >
> > > > non-XTAL clock:
> > > >
> > > > refclk {
> > > > compatible = "fixed-clock";
> > > > #clock cells = <0>;
> > > > clock-frequency = <1920>;
> > > > clock-output-names = "osc"; /* any better name ? */
> > > > };
> > >
> > > This starts looking a bit hacky. Using the output name as a flag is not
> > > very pretty.
> > >
> > > I think it would be better to have a separate flag for it in the wlan
> > > node. Like an optional "refclock-xtal" boolean or something. The
> > > downside of this is that we would be adding information about the clock
> > > details in the wilink node. :(
> > >
> > > OTOH, we could add a flag to the generic clock bind
Re: [alsa-devel] [PATCH] ASoC: Add PCM1681 codec driver.
On 06/26/2013 03:05 PM, Marek Belisko wrote:
[...]
> +static int pcm1681_deemph[] = { 44100, 48000, 32000 };
const
> +
> +static int pcm1681_set_deemph(struct snd_soc_codec *codec)
> +{
> + struct pcm1681_private *priv = snd_soc_codec_get_drvdata(codec);
> + int i = 0, val = -1, ret;
> +
> + if (priv->deemph)
> + for (i = 0; i < ARRAY_SIZE(pcm1681_deemph); i++)
> + if (pcm1681_deemph[i] == priv->rate)
> + val = i;
> +
> + /* enable choosen frequency */
> + if (val != -1)
> + regmap_update_bits(priv->regmap, PCM1681_DEEMPH_CONTROL,
> + PCM1681_DEEMPH_RATE_MASK, val);
So if the current sample rate doesn't match any of the available deempth rates
the current setting is kept. This doesn't seem right.
> +
> + /* enable/disable deemphasis functionality */
> + ret = regmap_update_bits(priv->regmap, PCM1681_DEEMPH_CONTROL,
> + PCM1681_DEEMPH_MASK, priv->deemph);
> +
> + return ret;
> +}
> +
[...]
> +
> +static int pcm1681_digital_mute(struct snd_soc_dai *dai, int mute)
> +{
> + struct snd_soc_codec *codec = dai->codec;
> + struct pcm1681_private *priv = snd_soc_codec_get_drvdata(codec);
> + int ret, val = 0;
> +
> + if (mute)
> + val = PCM1681_SOFT_MUTE_ALL;
> +
> + ret = regmap_write(priv->regmap, PCM1681_SOFT_MUTE, val);
How about just
return regmap_write(...)
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
[...]
> +static const DECLARE_TLV_DB_SCALE(pcm1681_dac_tlv, -6350, 50, 1);
> +
> +static const struct snd_kcontrol_new pcm1681_controls[] = {
> + SOC_DOUBLE_R_TLV("PCM1681 Channel 1/2 Playback Volume",
> + PCM1681_ATT_CONTROL(1), PCM1681_ATT_CONTROL(2), 0,
> + 0x7f, 0, pcm1681_dac_tlv),
> + SOC_DOUBLE_R_TLV("PCM1681 Channel 3/4 Playback Volume",
> + PCM1681_ATT_CONTROL(3), PCM1681_ATT_CONTROL(4), 0,
> + 0x7f, 0, pcm1681_dac_tlv),
> + SOC_DOUBLE_R_TLV("PCM1681 Channel 5/6 Playback Volume",
> + PCM1681_ATT_CONTROL(5), PCM1681_ATT_CONTROL(6), 0,
> + 0x7f, 0, pcm1681_dac_tlv),
> + SOC_DOUBLE_R_TLV("PCM1681 Channel 7/8 Playback Volume",
> + PCM1681_ATT_CONTROL(7), PCM1681_ATT_CONTROL(8), 0,
> + 0x7f, 0, pcm1681_dac_tlv),
> + SOC_SINGLE_BOOL_EXT("PCM1681 De-emphasis Switch", 0,
> + pcm1681_get_deemph, pcm1681_put_deemph),
> +};
The name of the codec should probably not be in the control names.
[...]
> +#ifdef CONFIG_OF
> +static const struct of_device_id pcm1681_dt_ids[] = {
> + { .compatible = "ti,pcm1681", },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, pcm1681_dt_ids);
> +#endif
> +
> +static const struct regmap_config pcm1681_regmap = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = ARRAY_SIZE(pcm1681_reg_defaults),
max_register is the last register in the register map, so usually this would be
ARRAY_SIZE(...) + 1
> + .reg_defaults = pcm1681_reg_defaults,
> + .num_reg_defaults = ARRAY_SIZE(pcm1681_reg_defaults),
> + .writeable_reg = pcm1681_writeable_reg,
> + .readable_reg = pcm1681_accessible_reg,
> +};
[...]
> +
> +static struct snd_soc_codec_driver soc_codec_dev_pcm1681 = {
> + .probe = pcm1681_probe,
> + .remove = pcm1681_remove,
> + .controls = pcm1681_controls,
> + .num_controls = ARRAY_SIZE(pcm1681_controls),
> +};
> +
> +#if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE)
Since the driver only supports I2C there is no need for this ifdef
[...]
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RFC 3/3] dt:net:stmmac: Add dt specific phy reset callback support.
From: Srinivas Kandagatla
This patch adds phy reset callback support for stmmac driver via device
trees. It adds three new properties to gmac device tree bindings to
define the reset signal via gpio.
With this patch users can conveniently pass reset gpio number with pre,
pulse and post delay in micro secs via DTs.
active low:
_
| |
| |
|___|
active high:
| |
| |
| |___
Signed-off-by: Srinivas Kandagatla
---
Documentation/devicetree/bindings/net/stmmac.txt |6
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 31 +
2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
b/Documentation/devicetree/bindings/net/stmmac.txt
index e1ddfcc..261c563 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -13,6 +13,12 @@ Required properties:
- phy-mode: String, operation mode of the PHY interface.
Supported values are: "mii", "rmii", "gmii", "rgmii".
- snps,phy-addrphy address to connect to.
+- snps,reset-gpio gpio number for phy reset.
+- snps,reset-active-low boolean flag to indicate if phy reset is active low.
+- snps,reset-delays-us is triplet of delays
+ The 1st cell is reset pre-delay in micro seconds.
+ The 2nd cell is reset pulse in micro seconds.
+ The 3rd cell is reset post-delay in micro seconds.
- snps,pbl Programmable Burst Length
- snps,fixed-burst Program the DMA to use the fixed burst mode
- snps,mixed-burst Program the DMA to use the mixed burst mode
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index cc15039..677ed16 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -27,6 +27,9 @@
#include
#include
#include
+#include
+#include
+
#include
#include "stmmac.h"
@@ -131,6 +134,34 @@ static int stmmac_mdio_reset(struct mii_bus *bus)
struct net_device *ndev = bus->priv;
struct stmmac_priv *priv = netdev_priv(ndev);
unsigned int mii_address = priv->hw->mii.addr;
+ struct device *dev = priv->device;
+
+ if (dev->of_node) {
+ int reset_gpio, active_low;
+ struct device_node *np = dev->of_node;
+ u32 delays[3] = {0,};
+
+ if (!np)
+ return 0;
+
+ reset_gpio = of_get_named_gpio(np, "snps,reset-gpio", 0);
+ if (reset_gpio < 0)
+ return 0;
+
+ active_low = of_property_read_bool(np,
+ "snps,reset-active-low");
+ of_property_read_u32_array(np,
+ "snps,reset-delays-us", delays, 3);
+
+ gpio_request(reset_gpio, "mdio-reset");
+ gpio_direction_output(reset_gpio, active_low ? 1 : 0);
+ udelay(delays[0]);
+ gpio_set_value(reset_gpio, active_low ? 0 : 1);
+ udelay(delays[1]);
+ gpio_set_value(reset_gpio, active_low ? 1 : 0);
+ udelay(delays[2]);
+ gpio_free(reset_gpio);
+ }
if (priv->plat->mdio_bus_data->phy_reset) {
pr_debug("stmmac_mdio_reset: calling phy_reset\n");
--
1.7.6.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RFC 1/3] dt:net:stmmac: Allocate platform data only if its NULL.
From: Srinivas Kandagatla
In some DT use-cases platform data might be already allocated and passed
via AUXDATA. These are the cases where machine level code populates few
callbacks in the platform data.
This patch adds check and reuses platform_data if its valid, before
allocating a new one.
Signed-off-by: Srinivas Kandagatla
---
.../net/ethernet/stmicro/stmmac/stmmac_platform.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 1d3780f..5907920 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -92,8 +92,10 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
if (IS_ERR(addr))
return PTR_ERR(addr);
+ plat_dat = pdev->dev.platform_data;
if (pdev->dev.of_node) {
- plat_dat = devm_kzalloc(&pdev->dev,
+ if (!plat_dat)
+ plat_dat = devm_kzalloc(&pdev->dev,
sizeof(struct plat_stmmacenet_data),
GFP_KERNEL);
if (!plat_dat) {
@@ -106,8 +108,6 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
pr_err("%s: main dt probe failed", __func__);
return ret;
}
- } else {
- plat_dat = pdev->dev.platform_data;
}
/* Custom initialisation (if needed)*/
--
1.7.6.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RFC 2/3] dt:net:stmmac: Add support to dwmac version 3.610 and 3.710
From: Srinivas Kandagatla
This patch adds dt support to dwmac version 3.610 and 3.710 these
versions are integrated in STiH415 and STiH416 ARM A9 SOCs.
To support these IP version, some of the device tree properties are
extended.
Signed-off-by: Srinivas Kandagatla
---
Documentation/devicetree/bindings/net/stmmac.txt |4 +++
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 25
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
b/Documentation/devicetree/bindings/net/stmmac.txt
index 060bbf0..e1ddfcc 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -12,6 +12,10 @@ Required properties:
property
- phy-mode: String, operation mode of the PHY interface.
Supported values are: "mii", "rmii", "gmii", "rgmii".
+- snps,phy-addrphy address to connect to.
+- snps,pbl Programmable Burst Length
+- snps,fixed-burst Program the DMA to use the fixed burst mode
+- snps,mixed-burst Program the DMA to use the mixed burst mode
Optional properties:
- mac-address: 6 bytes, mac address
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 5907920..060758d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -29,17 +29,26 @@
#include "stmmac.h"
#ifdef CONFIG_OF
+
static int stmmac_probe_config_dt(struct platform_device *pdev,
struct plat_stmmacenet_data *plat,
const char **mac)
{
struct device_node *np = pdev->dev.of_node;
+ struct stmmac_dma_cfg *dma_cfg;
if (!np)
return -ENODEV;
*mac = of_get_mac_address(np);
plat->interface = of_get_phy_mode(np);
+
+ plat->bus_id = of_alias_get_id(np, "ethernet");
+ if (plat->bus_id < 0)
+ plat->bus_id = 0;
+
+ of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr);
+
plat->mdio_bus_data = devm_kzalloc(&pdev->dev,
sizeof(struct stmmac_mdio_bus_data),
GFP_KERNEL);
@@ -51,11 +60,25 @@ static int stmmac_probe_config_dt(struct platform_device
*pdev,
*/
if (of_device_is_compatible(np, "st,spear600-gmac") ||
of_device_is_compatible(np, "snps,dwmac-3.70a") ||
+ of_device_is_compatible(np, "snps,dwmac-3.610") ||
of_device_is_compatible(np, "snps,dwmac")) {
plat->has_gmac = 1;
plat->pmt = 1;
}
+ if (of_device_is_compatible(np, "snps,dwmac-3.610") ||
+ of_device_is_compatible(np, "snps,dwmac-3.710")) {
+ plat->enh_desc = 1;
+ plat->bugged_jumbo = 1;
+ plat->force_sf_dma_mode = 1;
+ }
+
+ dma_cfg = devm_kzalloc(&pdev->dev, sizeof(*dma_cfg), GFP_KERNEL);
+ plat->dma_cfg = dma_cfg;
+ of_property_read_u32(np, "snps,pbl", &dma_cfg->pbl);
+ dma_cfg->fixed_burst = of_property_read_bool(np, "snps,fixed-burst");
+ dma_cfg->mixed_burst = of_property_read_bool(np, "snps,mixed-burst");
+
return 0;
}
#else
@@ -230,7 +253,9 @@ static const struct dev_pm_ops stmmac_pltfr_pm_ops;
static const struct of_device_id stmmac_dt_ids[] = {
{ .compatible = "st,spear600-gmac"},
+ { .compatible = "snps,dwmac-3.610"},
{ .compatible = "snps,dwmac-3.70a"},
+ { .compatible = "snps,dwmac-3.710"},
{ .compatible = "snps,dwmac"},
{ /* sentinel */ }
};
--
1.7.6.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RFC 0/3] extend stmmac DT support.
From: Srinivas Kandagatla Hi Peppe, This patch series adds support to new gmac versions 3.6.10 and 3.710, these versions of IP are integrated into ST STiH415/STiH416 SOCs. This patchset also adds phy reset capablity to stmmac-mdio driver via DT. Thanks, srini Srinivas Kandagatla (3): dt:net:stmmac: Allocate platform data only if its NULL. dt:net:stmmac: Add support to dwmac version 3.610 and 3.710 dt:net:stmmac: Add dt specific phy reset callback support. Documentation/devicetree/bindings/net/stmmac.txt | 10 ++ drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 31 .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 31 ++-- 3 files changed, 69 insertions(+), 3 deletions(-) -- 1.7.6.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V3 1/2] tps6507x-ts: Add DT support
Hi Dmitry On Wed, Jun 12, 2013 at 12:23 PM, Vishwanathrao Badarkhe, Manish < manish...@ti.com> wrote: > Hi Dmitry, > > On Mon, Jun 10, 2013 at 23:33:11, Dmitry Torokhov wrote: >> Manish, >> >> On Mon, Jun 10, 2013 at 10:23:16AM +, Vishwanathrao Badarkhe, Manish wrote: >> > Hi Dmitry, >> > >> > On Mon, Jun 10, 2013 at 11:34:42, Dmitry Torokhov wrote: >> > > Hi Manish, >> > > >> > > On Tue, May 21, 2013 at 02:24:17PM +0530, Vishwanathrao Badarkhe, Manish wrote: >> > > >> > > > + struct touchscreen_init_data *init_data = NULL; >> > > > + int err; >> > > > + >> > > > + if (node) >> > > > + node = of_find_node_by_name(node, "tsc"); >> > > >> > > Why do you have to locate OF node manually instead of already having it attached to the device stucture? >> > >> > As TPS6507x is mfd device containing two nodes, regulator and touchscreen. >> > It is necessary to use "of_find_node_by_name" to find child "tsc" node >> > of TPS6507x MFD device. >> >> I understand that TPS6507x is a MFD device, However, I still do not understand why you do not attach OF data to the child platform device representing touch screen when you create it. > > I gone through most of MFD devices in mainline kernel where "of_find_node_by_name" > function is used in order to populate child node properties. > See below example of max8925 MFD device. > > Max8025 MFD device has following modules > 1. Touch screen > 2. Charger > 3. Backlight > 4. regulator > > In DT case, device node for max8925 MFD device is in "arch/arm/boot/dts/mmp2-brownstone.dts" > file having child nodes as regulator, backlight and charger. > Respective drivers (regulator, backlight and charger) of max8925 MFD device used > "of_find_node_by_name" function in order to populate child node properties. > > Here, also same case for TPS6507x MFD device > > TPS6507x MFD device has two childs: > 1. regulator > 2. touch screen. > > Regulator driver for TPS6507x is already in mainline and using function > "of_find_node_by_name" to populate device tree properties for regulators. > On similar lines I used "of_find_node_by_name" to populate device > tree properties for touch screen. > > Still, I agreed that it is possible to attach OF data to child platform device > but it requires changes in MFD driver of TPS6507x. > > Please let me know your opinion about this. Please let me know so accordingly I will make changes in code. Regards Manish Badarkhe ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v10] i2c: exynos5: add High Speed I2C controller driver
Hi Naveen,
Looks mostly good, but see some comments inline.
On Wednesday 19 of June 2013 16:18:25 Naveen Krishna Chatradhi wrote:
> Adds support for High Speed I2C driver found in Exynos5 and
> later SoCs from Samsung.
>
> Driver only supports Device Tree method.
>
> Changes since v1:
> 1. Added FIFO functionality
> 2. Added High speed mode functionality
> 3. Remove SMBUS_QUICK
> 4. Remove the debugfs functionality
> 5. Use devm_* functions where ever possible
> 6. Driver is free from GPIO configs
> 7. Use OF data string "clock-frequency" to get the bus operating
> frequencies 8. Split the clock divisor calculation function
> 9. Add resets for the failed transacton cases
> 10. Removed retries as core does retries if -EAGAIN is returned
> 11. Removed mode from device tree info (use speed to distinguish
> the mode of operation)
> 12. Use wait_for_completion_timeout as the interruptible case is not
> tested well 13. few other bug fixes and cosmetic changes
>
> Signed-off-by: Taekgyun Ko
> Signed-off-by: Naveen Krishna Chatradhi
> Reviewed-by: Simon Glass
> Tested-by: Andrew Bresticker
> Signed-off-by: Yuvaraj Kumar C D
> Signed-off-by: Andrew Bresticker
> ---
>
> Changes since v9:
> Fixed below comments given by Wolfram, Thanks for the reivew.
> 1. Removed retries as core does retries if -EAGAIN is returned
> 2. Removed mode from device tree info (use speed to distinguish
>the mode of operation)
> 3. Use module_platform_driver macro instead of init and exit
> 4. Use wait_for_completion_timeout as the interruptible case is not
> tested well
>
> .../devicetree/bindings/i2c/i2c-exynos5.txt| 44 +
> drivers/i2c/busses/Kconfig |7 +
> drivers/i2c/busses/Makefile|1 +
> drivers/i2c/busses/i2c-exynos5.c | 861
> 4 files changed, 913 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
> create mode 100644 drivers/i2c/busses/i2c-exynos5.c
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
> b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt new file mode
> 100644
> index 000..805e018
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
> @@ -0,0 +1,44 @@
> +* Samsung's High Speed I2C controller
> +
> +The Samsung's High Speed I2C controller is used to interface with I2C
> devices +at various speeds ranging from 100khz to 3.4Mhz.
> +
> +Required properties:
> + - compatible: value should be.
> + -> "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
IMHO this compatible value is too wide. You might end up with new Exynos 5
SoC that has a high speed I2C controller as well, but slightly different,
requiring some extra quirks. Now exynos5 in compatible would suggest that
it covers all Exynos 5 SoCs, but such SoC would require new one.
Basically, my suggestion is to use a compatible value with name of first SoC
in which given IP appeared, as it is already done in most bindings.
> + - reg: physical base address of the controller and length of memory
> mapped +region.
> + - interrupts: interrupt number to the cpu.
> + - #address-cells: always 1 (for i2c addresses)
> + - #size-cells: always 0
> +
> + - Pinctrl:
> +- pinctrl-0: Pin control group to be used for this controller.
> +- pinctrl-names: Should contain only one value - "default".
> +
> +Optional properties:
> + - clock-frequency: Desired operating frequency in Hz of the bus.
> +-> If not specified, the default value is 100khz in fast-speed mode
> and + 1Mhz in high-speed mode.
> +-> If specified, The bus operates in high-speed mode only if the
> + clock-frequency is >= 1Mhz.
> +
> +Example:
> +
> +hsi2c@12ca {
> + compatible = "samsung,exynos5-hsi2c";
> + reg = <0x12ca 0x100>;
> + interrupts = <56>;
> + clock-frequency = <10>;
> +
> + pinctrl-0 = <&i2c4_bus>;
> + pinctrl-names = "default";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + s2mps11_pmic@66 {
> + compatible = "samsung,s2mps11-pmic";
> + reg = <0x66>;
> + };
> +};
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 96c6d82..fecbe66 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -434,6 +434,13 @@ config I2C_EG20T
> ML7213/ML7223/ML7831 is companion chip for Intel Atom E6xx series.
> ML7213/ML7223/ML7831 is completely compatible for Intel EG20T PCH.
>
> +config I2C_EXYNOS5
> + tristate "Exynos5 high-speed I2C driver"
> + depends on ARCH_EXYNOS5 && OF
> + help
> + Say Y here to include support for high-speed I2C controller in the
> + Exynos5 based Samsung SoCs.
> +
> config I2C_GPIO
> tristate "GPIO-based bitbanging I2C"
> depends on GPIOLIB
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 385f99d..
Re: [PATCH 3/4] PCI: Add driver for i.MX6 PCI Express
On 7/1/2013 12:45 PM, Sean Cross wrote: This adds a PCI Express port driver for the on-chip PCI Express port present on the i.MX6 SoC. It is based on the PCI Express driver available in the Freescale BSP. Signed-off-by: Sean Cross --- ... diff --git a/drivers/pci/pcie/pcie-imx.c b/drivers/pci/pcie/pcie-imx.c new file mode 100644 index 000..664679e --- /dev/null +++ b/drivers/pci/pcie/pcie-imx.c Should go to drivers/pci/host/ @@ -0,0 +1,1049 @@ +/* + * drivers/pci/pcie/pcie-imx.c + * ... +#define ATU_R_BaseAddress 0x900 +#define PCIE_PL_iATUVR (ATU_R_BaseAddress + 0x0) +#define PCIE_PL_iATURC1 (ATU_R_BaseAddress + 0x4) +#define PCIE_PL_iATURC2 (ATU_R_BaseAddress + 0x8) +#define PCIE_PL_iATURLBA (ATU_R_BaseAddress + 0xC) +#define PCIE_PL_iATURUBA (ATU_R_BaseAddress + 0x10) +#define PCIE_PL_iATURLA (ATU_R_BaseAddress + 0x14) +#define PCIE_PL_iATURLTA (ATU_R_BaseAddress + 0x18) +#define PCIE_PL_iATURUTA (ATU_R_BaseAddress + 0x1C) I may be wrong, but from these offset it seems to me that it is SNPS controller. If yes, then please go through comments of "[PATCH V1-10 0/4] PCIe support for Samsung Exynos5440 SoC" Regards Pratyush ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/4] ARM: Enable PCI Express on ARM
On 7/1/2013 12:45 PM, Sean Cross wrote: Some ARM devices have PCI Express hardware, and should be able to take advantage of PCI Express code present in the common driver files. Enable PCI Express on ARM, when PCI is available. Signed-off-by: Sean Cross --- arch/arm/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 136f263..2f51f13 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1418,6 +1418,8 @@ config PCI_HOST_ITE8152 source "drivers/pci/Kconfig" +source "drivers/pci/pcie/Kconfig" + [PATCH V10 2/4] ARM: EXYNOS: Enable PCIe support for Exynos5440 does the same thing. source "drivers/pcmcia/Kconfig" endmenu ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 2/5] ARM: dts: imx27: Add imx framebuffer device
On Fri, Jun 28, 2013 at 07:10:06PM +0400, Alexander Shiyan wrote:
> > Signed-off-by: Markus Pargmann
> > ---
> > arch/arm/boot/dts/imx27.dtsi | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
> > index 8603886..10dcbd3 100644
> > --- a/arch/arm/boot/dts/imx27.dtsi
> > +++ b/arch/arm/boot/dts/imx27.dtsi
> > @@ -342,6 +342,15 @@
> > reg = <0x1002 0x2>;
> > ranges;
> >
> > + imxfb: fb@10021000 {
>
> If it can be fixed while applying, it would be right to use just "fb" here.
> We now use a lot of devices without "imx"-prefix, so I do not see any need to
> use it here.
I actually prefer to use the block name if it's not a thing defined by
ePAPR. In this case, it's "lcdc". But since "fb" is already used in
compatible. Okay, I fixed it up by dropping "imx" prefix.
Applied the whole series, thanks.
Shawn
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/4] PCI: Add driver for i.MX6 PCI Express
On Monday, July 1, 2013 at 3:51 PM, Alexander Shiyan wrote:
> > This adds a PCI Express port driver for the on-chip PCI Express port
> > present on the i.MX6 SoC. It is based on the PCI Express driver available
> > in the Freescale BSP.
> >
> > Signed-off-by: Sean Cross mailto:x...@kosagi.com)>
> ...
> > +++ b/Documentation/devicetree/bindings/pci/imx6q-pcie.txt
> > @@ -0,0 +1,20 @@
> > +* Freescale i.MX6Q PCI Express bridge
> > +
> > +Example (i.MX6Q)
> > + pcie: pcie@01ffc000 {
> > + compatible = "fsl,imx6q-pcie";
> > + reg = <0x01ffc000 0x4000>,
> > + <0x0100 0x10>,
> > + <0x0110 0xe0>,
> > + <0x01f0 0xfc000>;
> > + interrupts = <0 122 0x04>;
> > + clocks = <&clks 186>, <&clks 189>, <&clks 196>,
> > + <&clks 198>, <&clks 144>;
> > + clock-names = "sata_ref", "pcie_ref_125m", "lvds1_sel",
> > + "lvds1", "pcie_axi";
> > + power-enable = <&gpio7 12 0>;
> > + pcie-reset = <&gpio3 29 0>;
>
>
>
> Can this be replaced with regulator/reset API?
I agree that power-enable might be better replaced with regulator API calls,
and I'll rework this patch to incorporate a regulator.
I hadn't heard of the reset API before, and I note in the documentation that it
says:
Reset signals for whole standalone chips are most likely better represented
as
GPIOs, although there are likely to be exceptions to this rule.
This is a reset line going directly to a PCIe slot, which I think counts as a
"standalone chip".
> > + wake-up = <&gpio3 22 0>;
> > + disable-endpoint = <&gpio2 16 0>;
> > + };
>
>
>
> ---
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] tty: serial: Add initial MSM UART High Speed Lite driver
From: "Ivan T. Ivanov"
This is a tty driver with console support for Qualcomm's UART
controllers found in the MSM8974 chipsets. Driver is completely
based on implementation found in codeaurora.org msm_serial_hs_lite
with Android dependences removed. Other changes include, moved to
device managed resources and few cleanups.
Driver functionality was tested in LEGACY_HSUART mode.
Signed-off-by: Ivan T. Ivanov
---
.../bindings/tty/serial/msm_serial_hsl.txt | 52 +
drivers/tty/serial/Kconfig | 18 +
drivers/tty/serial/Makefile|1 +
drivers/tty/serial/msm_serial_hsl.c| 1399
drivers/tty/serial/msm_serial_hsl.h| 294
5 files changed, 1764 insertions(+)
create mode 100644
Documentation/devicetree/bindings/tty/serial/msm_serial_hsl.txt
create mode 100644 drivers/tty/serial/msm_serial_hsl.c
create mode 100644 drivers/tty/serial/msm_serial_hsl.h
diff --git a/Documentation/devicetree/bindings/tty/serial/msm_serial_hsl.txt
b/Documentation/devicetree/bindings/tty/serial/msm_serial_hsl.txt
new file mode 100644
index 000..972552f
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/msm_serial_hsl.txt
@@ -0,0 +1,52 @@
+* Qualcomm MSM HSUART Lite
+
+Required properties:
+- compatible :
+ "qcom,msm-lsuart-v14" to be used for UARTDM Core v1.4
+
+- reg :
+ offset and length of the register set for both the device,
+ UART core and GBSI core
+
+- reg-names :
+ "uart_mem" to be used as name of the UART core
+ "gbsi_mem" to be used as name of the GBSI core
+
+The registers for the "qcom,msm-lsuart-v14" device have specify
+UART core block. GSBI reg is optional if specified driver will use
+GSBI specific functionality.
+
+- interrupts : interrupts for UART core
+
+- clocks : Must contain an entry for each entry in clock-names.
+
+- clock-names : Must include the following entries:
+ "core_clk" - mandatory
+ "iface_clk" - optional
+
+For details see:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Example:
+
+ serial@f991e000 {
+ compatible = "qcom,msm-lsuart-v14";
+ reg = <0xf991e000 0x1000>;
+ reg-names = "uart_mem";
+ interrupts = <0 108 0>;
+ clocks = <&blsp1_uart2_apps_cxc>, <&blsp1_ahb_cxc>;
+ clock-names = "core_clk", "iface_clk";
+ };
+
+Aliases :
+An alias may be optionally used to bind the UART device to a TTY device
+(ttyHSL) with a given alias number. Aliases are of the form
+uart where is an integer representing the alias number to use.
+On systems with multiple UART devices present, an alias may optionally be
+defined for such devices. The alias value should be from 0 to 255.
+
+Example:
+
+ aliases {
+ uart4 = &uart7; // This device will be enumerated as ttyHSL4
+ };
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 7e7006f..4482bc7 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1046,6 +1046,24 @@ config SERIAL_MSM_HS
Choose M here to compile it as a module. The module will be
called msm_serial_hs.
+config SERIAL_MSM_HSL
+ tristate "MSM High speed serial lite mode driver"
+ depends on ARM && ARCH_MSM
+ select SERIAL_CORE
+ default n
+ help
+ Select this module to enable MSM high speed lite mode driver
+ for UART controllers found in MSM8974 SoC's
+
+ Choose M here to compile it as a module. The module will be
+ called msm_serial_hsl.
+
+config SERIAL_MSM_HSL_CONSOLE
+ bool "MSM High speed serial lite mode console support"
+ depends on SERIAL_MSM_HSL=y
+ select SERIAL_CORE_CONSOLE
+ default n
+
config SERIAL_VT8500
bool "VIA VT8500 on-chip serial port support"
depends on ARCH_VT8500
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index eedfec4..86c023b 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_SERIAL_ATMEL) += atmel_serial.o
obj-$(CONFIG_SERIAL_UARTLITE) += uartlite.o
obj-$(CONFIG_SERIAL_MSM) += msm_serial.o
obj-$(CONFIG_SERIAL_MSM_HS) += msm_serial_hs.o
+obj-$(CONFIG_SERIAL_MSM_HSL) += msm_serial_hsl.o
obj-$(CONFIG_SERIAL_NETX) += netx-serial.o
obj-$(CONFIG_SERIAL_OF_PLATFORM) += of_serial.o
obj-$(CONFIG_SERIAL_OF_PLATFORM_NWPSERIAL) += nwpserial.o
diff --git a/drivers/tty/serial/msm_serial_hsl.c
b/drivers/tty/serial/msm_serial_hsl.c
new file mode 100644
index 000..56c15a8
--- /dev/null
+++ b/drivers/tty/serial/msm_serial_hsl.c
@@ -0,0 +1,1399 @@
+/*
+ * drivers/tty/serial/msm_serial_hsl.c - driver for serial device and console
+ *
+ * Copyright (C) 2007 Google, Inc.
+ * Copyright (c) 2010-2013, The Linux Foundation. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License versio
[RFC PATCH 12/13] sound: wm8731: rework power management
From: Nicolas Ferre
- preserve crystal oscillator across suspend/resume sequence:
enabled by default,it should be kept enabled on resume.
- if codec is in active state: set the active bit at resume time.
Signed-off-by: Nicolas Ferre
Signed-off-by: Uwe Kleine-König
---
sound/soc/codecs/wm8731.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/wm8731.c b/sound/soc/codecs/wm8731.c
index 5276062..3cf6b20 100644
--- a/sound/soc/codecs/wm8731.c
+++ b/sound/soc/codecs/wm8731.c
@@ -465,7 +465,9 @@ static int wm8731_set_bias_level(struct snd_soc_codec
*codec,
snd_soc_write(codec, WM8731_PWR, reg | 0x0040);
break;
case SND_SOC_BIAS_OFF:
- snd_soc_write(codec, WM8731_PWR, 0x);
+ snd_soc_write(codec, WM8731_ACTIVE, 0x0);
+ /* standby: keep crystal oscillator enabled */
+ snd_soc_write(codec, WM8731_PWR, 0x00df);
regulator_bulk_disable(ARRAY_SIZE(wm8731->supplies),
wm8731->supplies);
regcache_mark_dirty(wm8731->regmap);
@@ -516,6 +518,8 @@ static int wm8731_suspend(struct snd_soc_codec *codec)
static int wm8731_resume(struct snd_soc_codec *codec)
{
wm8731_set_bias_level(codec, SND_SOC_BIAS_STANDBY);
+ if (codec->active)
+ snd_soc_write(codec, WM8731_ACTIVE, 0x0001);
return 0;
}
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH 13/13] sound: codec: wm8371: correct capture line/mic
With the "switch" text, we can't enable the line and mic capture in
alsamixer.
Signed-off-by: Richard Genoud
---
sound/soc/codecs/wm8731.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/wm8731.c b/sound/soc/codecs/wm8731.c
index 3cf6b20..dae1403 100644
--- a/sound/soc/codecs/wm8731.c
+++ b/sound/soc/codecs/wm8731.c
@@ -164,10 +164,10 @@ SOC_DOUBLE_R("Master Playback ZC Switch", WM8731_LOUT1V,
WM8731_ROUT1V,
SOC_DOUBLE_R_TLV("Capture Volume", WM8731_LINVOL, WM8731_RINVOL, 0, 31, 0,
in_tlv),
-SOC_DOUBLE_R("Line Capture Switch", WM8731_LINVOL, WM8731_RINVOL, 7, 1, 1),
+SOC_DOUBLE_R("Line Capture", WM8731_LINVOL, WM8731_RINVOL, 7, 1, 1),
SOC_SINGLE_TLV("Mic Boost Volume", WM8731_APANA, 0, 1, 0, mic_tlv),
-SOC_SINGLE("Mic Capture Switch", WM8731_APANA, 1, 1, 1),
+SOC_SINGLE("Mic Capture", WM8731_APANA, 1, 1, 1),
SOC_SINGLE_TLV("Sidetone Playback Volume", WM8731_APANA, 6, 3, 1,
sidetone_tlv),
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH 10/13] sound: atmel_ssc_dai: PM: actually stopping clock on suspend/resume
From: Nicolas Ferre
Stop SSC clock on suspend/resume cycle checking if the controller is actually
initialized. This will save power while sleeping.
Signed-off-by: Nicolas Ferre
Signed-off-by: Uwe Kleine-König
---
sound/soc/atmel/atmel_ssc_dai.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index f3fdfa0..14da27a 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -659,12 +659,10 @@ static int atmel_ssc_prepare(struct snd_pcm_substream
*substream,
#ifdef CONFIG_PM
static int atmel_ssc_suspend(struct snd_soc_dai *cpu_dai)
{
- struct atmel_ssc_info *ssc_p;
+ struct atmel_ssc_info *ssc_p = &ssc_info[cpu_dai->id];
if (!cpu_dai->active)
- return 0;
-
- ssc_p = &ssc_info[cpu_dai->id];
+ goto out;
/* Save the status register before disabling transmit and receive */
ssc_p->ssc_state.ssc_sr = ssc_readl(ssc_p->ssc->regs, SR);
@@ -680,6 +678,11 @@ static int atmel_ssc_suspend(struct snd_soc_dai *cpu_dai)
ssc_p->ssc_state.ssc_tcmr = ssc_readl(ssc_p->ssc->regs, TCMR);
ssc_p->ssc_state.ssc_tfmr = ssc_readl(ssc_p->ssc->regs, TFMR);
+out:
+ if (ssc_p->initialized) {
+ pr_debug("atmel_ssc_dai: suspend - stop clock\n");
+ clk_disable(ssc_p->ssc->clk);
+ }
return 0;
}
@@ -687,14 +690,17 @@ static int atmel_ssc_suspend(struct snd_soc_dai *cpu_dai)
static int atmel_ssc_resume(struct snd_soc_dai *cpu_dai)
{
- struct atmel_ssc_info *ssc_p;
+ struct atmel_ssc_info *ssc_p = &ssc_info[cpu_dai->id];
u32 cr;
+ if (ssc_p->initialized) {
+ pr_debug("atmel_ssc_dai: resume - restart clock\n");
+ clk_enable(ssc_p->ssc->clk);
+ }
+
if (!cpu_dai->active)
return 0;
- ssc_p = &ssc_info[cpu_dai->id];
-
/* restore SSC register settings */
ssc_writel(ssc_p->ssc->regs, TFMR, ssc_p->ssc_state.ssc_tfmr);
ssc_writel(ssc_p->ssc->regs, TCMR, ssc_p->ssc_state.ssc_tcmr);
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH 11/13] sound: atmel-pcm-dma: check pointer before dereference
If platform_data is NULL, filter() is called with a NULL slave
parameter.
Signed-off-by: Richard Genoud
---
sound/soc/atmel/atmel-pcm-dma.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/sound/soc/atmel/atmel-pcm-dma.c b/sound/soc/atmel/atmel-pcm-dma.c
index 1d38fd0..b20dbba 100644
--- a/sound/soc/atmel/atmel-pcm-dma.c
+++ b/sound/soc/atmel/atmel-pcm-dma.c
@@ -96,6 +96,9 @@ static bool filter(struct dma_chan *chan, void *slave)
{
struct at_dma_slave *sl = slave;
+ if (!sl)
+ return false;
+
if (sl->dma_dev == chan->device->dev) {
chan->private = sl;
return true;
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH 05/13] ARM: AT91: DTS: sam9x5ek: add WM8731 codec
The WM8731 codec on sam9x5ek board is on i2c, address 1A
Signed-off-by: Richard Genoud
---
arch/arm/boot/dts/at91sam9x5ek.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi
b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index b753855..a81a1a6 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -59,6 +59,11 @@
i2c0: i2c@f801 {
status = "okay";
+
+ wm8731: wm8731@1a {
+ compatible = "wm8731";
+ reg = <0x1a>;
+ };
};
pinctrl@f400 {
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH 09/13] sound: atmel-pcm: don't return ok if pcm-dma is not implemented
If DMA is not selected, atmel_pcm_dma_platform_register() should fail.
Like that, the driver knows it can't use it.
Signed-off-by: Richard Genoud
---
sound/soc/atmel/atmel-pcm.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/atmel/atmel-pcm.h b/sound/soc/atmel/atmel-pcm.h
index 12ae814..c0a01fa 100644
--- a/sound/soc/atmel/atmel-pcm.h
+++ b/sound/soc/atmel/atmel-pcm.h
@@ -109,7 +109,7 @@ void atmel_pcm_dma_platform_unregister(struct device *dev);
#else
static inline int atmel_pcm_dma_platform_register(struct device *dev)
{
- return 0;
+ return -1;
}
static inline void atmel_pcm_dma_platform_unregister(struct device *dev)
{
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH 07/13] ARM: AT91: DTS: sam9x5ek: enable SSC
Enable the SSC needed for the WM8731 codec
Signed-off-by: Richard Genoud
---
arch/arm/boot/dts/at91sam9x5ek.dtsi |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi
b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index 77e4073..4f3584c 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -95,6 +95,10 @@
watchdog@fe40 {
status = "okay";
};
+
+ ssc0: ssc@f001 {
+ status = "okay";
+ };
};
usb0: ohci@0060 {
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH 06/13] ARM: AT91: DTS: sam9x5ek: add sound configuration
The sam9x5ek board has 2 jacks:
headphone wired on RHPOUT/LHPOUT of the wm8731
line in wired on LLINEIN/RLINEIN of the wm8731
Signed-off-by: Richard Genoud
---
arch/arm/boot/dts/at91sam9x5ek.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi
b/arch/arm/boot/dts/at91sam9x5ek.dtsi
index a81a1a6..77e4073 100644
--- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
+++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
@@ -109,4 +109,22 @@
status = "okay";
};
};
+
+ sound {
+ compatible = "atmel,sam9x5-audio-wm8731";
+
+ atmel,model = "wm8731 @ AT91SAM9X5EK";
+
+ atmel,audio-routing =
+ "Headphone Jack", "RHPOUT",
+ "Headphone Jack", "LHPOUT",
+ "LLINEIN", "Line In Jack",
+ "RLINEIN", "Line In Jack";
+
+ atmel,ssc-controller = <&ssc0>;
+ atmel,audio-codec = <&wm8731>;
+ atmel,format = "i2s";
+ atmel,bitclock-master;
+ atmel,frame-master;
+ };
};
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH 08/13] sound: sam9x5_wm8731: machine driver for at91sam9x5 wm8731 boards
From: Nicolas Ferre
Description of the Asoc machine driver for an at91sam9x5 based board
with a wm8731 audio DAC. Wm8731 is clocked by a crystal and used as a
master on the SSC/I2S interface. Its connections are a headphone jack
and an Line input jack.
[Richard: this is based on an old patch from Nicolas that I forward
ported and reworked to use only device tree]
Signed-off-by: Nicolas Ferre
Signed-off-by: Uwe Kleine-König
Signed-off-by: Richard Genoud
---
sound/soc/atmel/Kconfig | 12 ++
sound/soc/atmel/Makefile|2 +
sound/soc/atmel/sam9x5_wm8731.c | 232 +++
3 files changed, 246 insertions(+)
create mode 100644 sound/soc/atmel/sam9x5_wm8731.c
diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
index 3fdd87f..f24d601 100644
--- a/sound/soc/atmel/Kconfig
+++ b/sound/soc/atmel/Kconfig
@@ -13,6 +13,7 @@ config SND_ATMEL_SOC_PDC
config SND_ATMEL_SOC_DMA
tristate
depends on SND_ATMEL_SOC
+ select SND_SOC_DMAENGINE_PCM
config SND_ATMEL_SOC_SSC
tristate
@@ -32,6 +33,17 @@ config SND_AT91_SOC_SAM9G20_WM8731
Say Y if you want to add support for SoC audio on WM8731-based
AT91sam9g20 evaluation board.
+config SND_AT91_SOC_SAM9X5_WM8731
+ tristate "SoC Audio support for WM8731-based at91sam9x5 board"
+ depends on ATMEL_SSC && SND_ATMEL_SOC && SOC_AT91SAM9X5
+ select SND_ATMEL_SOC_SSC
+ select SND_ATMEL_SOC_DMA
+ select SND_ATMEL_SOC_PDC
+ select SND_SOC_WM8731
+ help
+ Say Y if you want to add support for audio SoC on an
+ at91sam9x5 based board that is using WM8731 codec.
+
config SND_AT91_SOC_AFEB9260
tristate "SoC Audio support for AFEB9260 board"
depends on ARCH_AT91 && ATMEL_SSC && ARCH_AT91 && MACH_AFEB9260 &&
SND_ATMEL_SOC
diff --git a/sound/soc/atmel/Makefile b/sound/soc/atmel/Makefile
index 41967cc..7784c09 100644
--- a/sound/soc/atmel/Makefile
+++ b/sound/soc/atmel/Makefile
@@ -11,6 +11,8 @@ obj-$(CONFIG_SND_ATMEL_SOC_SSC) += snd-soc-atmel_ssc_dai.o
# AT91 Machine Support
snd-soc-sam9g20-wm8731-objs := sam9g20_wm8731.o
+snd-soc-sam9x5-wm8731-objs := sam9x5_wm8731.o
obj-$(CONFIG_SND_AT91_SOC_SAM9G20_WM8731) += snd-soc-sam9g20-wm8731.o
+obj-$(CONFIG_SND_AT91_SOC_SAM9X5_WM8731) += snd-soc-sam9x5-wm8731.o
obj-$(CONFIG_SND_AT91_SOC_AFEB9260) += snd-soc-afeb9260.o
diff --git a/sound/soc/atmel/sam9x5_wm8731.c b/sound/soc/atmel/sam9x5_wm8731.c
new file mode 100644
index 000..83ca457
--- /dev/null
+++ b/sound/soc/atmel/sam9x5_wm8731.c
@@ -0,0 +1,232 @@
+/*
+ * sam9x5_wm8731 -- SoC audio for AT91SAM9X5-based boards
+ * that are using WM8731 as codec.
+ *
+ * Copyright (C) 2011 Atmel,
+ * Nicolas Ferre
+ *
+ * Based on sam9g20_wm8731.c by:
+ * Sedji Gaouaou
+ *
+ * GPL
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "../codecs/wm8731.h"
+#include "atmel-pcm.h"
+#include "atmel_ssc_dai.h"
+
+#define MCLK_RATE 12288000
+
+#define DRV_NAME "sam9x5-snd-wm8731"
+
+/*
+ * Audio paths on at91sam9x5ek board:
+ *
+ * |A| > | | ---R> Headphone Jack
+ * |T| <\| WM | ---L--/
+ * |9| ---> CLK <--> | 8751 | <--R- Line In Jack
+ * |1| < | | <--L--/
+ */
+static const struct snd_soc_dapm_widget at91sam9x5ek_dapm_widgets[] = {
+ SND_SOC_DAPM_HP("Headphone Jack", NULL),
+ SND_SOC_DAPM_LINE("Line In Jack", NULL),
+};
+
+/*
+ * Logic for a wm8731 as connected on a at91sam9x5 based board.
+ */
+static int at91sam9x5ek_wm8731_init(struct snd_soc_pcm_runtime *rtd)
+{
+ struct snd_soc_codec *codec = rtd->codec;
+ struct snd_soc_dai *codec_dai = rtd->codec_dai;
+ struct snd_soc_dapm_context *dapm = &codec->dapm;
+ struct device *dev = rtd->dev;
+ int ret;
+
+ dev_dbg(dev, "ASoC: at91sam9x5ek_wm8731_init() called\n");
+
+ /*
+* remove some not supported rates in relation with clock
+* provided to the wm8731 codec
+*/
+ switch (MCLK_RATE) {
+ case 12288000:
+ codec_dai->driver->playback.rates &= SNDRV_PCM_RATE_8000 |
+SNDRV_PCM_RATE_32000 |
+SNDRV_PCM_RATE_48000 |
+SNDRV_PCM_RATE_96000;
+ codec_dai->driver->capture.rates &= SNDRV_PCM_RATE_8000 |
+ SNDRV_PCM_RATE_32000 |
+ SNDRV_PCM_RATE_48000 |
+ SNDRV_PCM_RATE_96000;
+ break;
+ case 1200:
+ /* all wm8731 rates supported */
+ break;
+ default:
+
[RFC PATCH 02/13] misc: atmel_ssc: keep the count of pdev->id
With device tree, pdev->id is always -1, so we introduce a local
counter.
Signed-off-by: Richard Genoud
---
drivers/misc/atmel-ssc.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index 3afbd82..d1ec5ab 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -173,6 +173,12 @@ out:
return err;
}
+/* counter of ssc devive instances.
+ * With device tree pdev->id is always -1, so we have to keep the
+ * count ourselves
+ */
+static int ssc_device_id;
+
static int ssc_probe(struct platform_device *pdev)
{
struct resource *regs;
@@ -235,6 +241,7 @@ static int ssc_probe(struct platform_device *pdev)
}
spin_lock(&user_lock);
+ pdev->id = ssc_device_id++;
list_add_tail(&ssc->list, &ssc_list);
spin_unlock(&user_lock);
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH 04/13] ARM: at91: DTS: sam9x5: add SSC DMA parameters
Signed-off-by: Richard Genoud --- arch/arm/boot/dts/at91sam9x5.dtsi |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi index 57d45f5..cf78ac0 100644 --- a/arch/arm/boot/dts/at91sam9x5.dtsi +++ b/arch/arm/boot/dts/at91sam9x5.dtsi @@ -542,6 +542,9 @@ compatible = "atmel,at91sam9g45-ssc"; reg = <0xf001 0x4000>; interrupts = <28 IRQ_TYPE_LEVEL_HIGH 5>; + dmas = <&dma0 1 AT91_DMA_CFG_PER_ID(13)>, + <&dma0 1 AT91_DMA_CFG_PER_ID(14)>; + dma-names = "tx", "rx"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>; status = "disabled"; -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH 00/13] audio support for at91sam9x5ek board
Hi, Here is some work I've done to make the sound work on sam9x5ek. It's based on Nicolas Ferre's and Uwe Kleine-König's work. (Atmel patch on 2.6.39 if I recall) I'd like to have some advice, mainly on the 1st patch "misc: atmel_ssc: add device tree DMA support". I do not clearly see what is the right way to add DMA DT support for this device, since it doesn't request a channel directly. patches applies on next-20130701 [I let the original signed-off from Nicolas and Uwe in place, I don't know if I should replace them by something like "originaly-signed-off-by" since the code has been changed.] Best regards, Richard. Nicolas Ferre (3): sound: sam9x5_wm8731: machine driver for at91sam9x5 wm8731 boards sound: atmel_ssc_dai: PM: actually stopping clock on suspend/resume sound: wm8731: rework power management Richard Genoud (10): misc: atmel_ssc: add device tree DMA support misc: atmel_ssc: keep the count of pdev->id ARM: at91: DTS: sam9x5: add clock for SSC DT entry ARM: at91: DTS: sam9x5: add SSC DMA parameters ARM: AT91: DTS: sam9x5ek: add WM8731 codec ARM: AT91: DTS: sam9x5ek: add sound configuration ARM: AT91: DTS: sam9x5ek: enable SSC sound: atmel-pcm: don't return ok if pcm-dma is not implemented sound: atmel-pcm-dma: check pointer before dereference sound: codec: wm8371: correct capture line/mic arch/arm/boot/dts/at91sam9x5.dtsi |3 + arch/arm/boot/dts/at91sam9x5ek.dtsi | 27 arch/arm/mach-at91/at91sam9x5.c |1 + drivers/misc/atmel-ssc.c| 63 + include/linux/atmel-ssc.h |2 + include/linux/platform_data/dma-atmel.h |2 + sound/soc/atmel/Kconfig | 12 ++ sound/soc/atmel/Makefile|2 + sound/soc/atmel/atmel-pcm-dma.c |3 + sound/soc/atmel/atmel-pcm.h |2 +- sound/soc/atmel/atmel_ssc_dai.c | 20 ++- sound/soc/atmel/sam9x5_wm8731.c | 232 +++ sound/soc/codecs/wm8731.c | 10 +- 13 files changed, 368 insertions(+), 11 deletions(-) create mode 100644 sound/soc/atmel/sam9x5_wm8731.c -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH 03/13] ARM: at91: DTS: sam9x5: add clock for SSC DT entry
Signed-off-by: Richard Genoud
---
arch/arm/mach-at91/at91sam9x5.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-at91/at91sam9x5.c b/arch/arm/mach-at91/at91sam9x5.c
index 2abee66..191eb4b 100644
--- a/arch/arm/mach-at91/at91sam9x5.c
+++ b/arch/arm/mach-at91/at91sam9x5.c
@@ -233,6 +233,7 @@ static struct clk_lookup periph_clocks_lookups[] = {
CLKDEV_CON_DEV_ID("mci_clk", "f000c000.mmc", &mmc1_clk),
CLKDEV_CON_DEV_ID("dma_clk", "ec00.dma-controller", &dma0_clk),
CLKDEV_CON_DEV_ID("dma_clk", "ee00.dma-controller", &dma1_clk),
+ CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.0", &ssc_clk),
CLKDEV_CON_DEV_ID("pclk", "f001.ssc", &ssc_clk),
CLKDEV_CON_DEV_ID(NULL, "f801.i2c", &twi0_clk),
CLKDEV_CON_DEV_ID(NULL, "f8014000.i2c", &twi1_clk),
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC PATCH 01/13] misc: atmel_ssc: add device tree DMA support
The ssc device has to fill the at_dma_slave structure with the
device tree informations.
Doing a of_dma_request_slave_channel()+dma_release_channel() for that
seems wrong (or at least not very clean).
Signed-off-by: Richard Genoud
---
drivers/misc/atmel-ssc.c| 56 +++
include/linux/atmel-ssc.h |2 ++
include/linux/platform_data/dma-atmel.h |2 ++
3 files changed, 60 insertions(+)
diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index f7b90661..3afbd82 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -19,7 +19,9 @@
#include
#include
+#include
#include
+#include
/* Serialize access to ssc_list and user count */
static DEFINE_SPINLOCK(user_lock);
@@ -127,12 +129,57 @@ static inline const struct atmel_ssc_platform_data *
__init
platform_get_device_id(pdev)->driver_data;
}
+static int atmel_ssc_get_dma_data(struct device_node *np,
+ struct at_dma_slave *sdata)
+{
+ struct dma_chan *chan;
+ struct at_dma_slave *rx_data;
+ int err = -1;
+
+ /*
+* FIXME: this is clearly not the right way to do it.
+* In order to fill struct at_dma_slave with both rx and tx data,
+* we request and release both channels.
+* Et voila ! We've got all the whole structure !
+* upside: it works(R)
+* downside: feels wrong, dirty, not optimized...
+*/
+ chan = of_dma_request_slave_channel(np, "tx");
+ if (!chan)
+ return err;
+
+ if (chan->private)
+ memcpy(sdata, chan->private, sizeof(*sdata));
+ else
+ goto out;
+
+ dma_release_channel(chan);
+
+ chan = of_dma_request_slave_channel(np, "rx");
+ if (!chan)
+ goto out;
+
+ if (chan->private) {
+ rx_data = chan->private;
+ sdata->cfg &= ~(ATC_SRC_PER_MSB(0xff) | ATC_SRC_PER(0xff));
+ sdata->cfg |= ATC_GET_SRC_ID(rx_data->cfg);
+ err = 0;
+ }
+
+out:
+ if (chan)
+ dma_release_channel(chan);
+
+ return err;
+}
+
static int ssc_probe(struct platform_device *pdev)
{
struct resource *regs;
struct ssc_device *ssc;
const struct atmel_ssc_platform_data *plat_dat;
struct pinctrl *pinctrl;
+ struct device_node *of = pdev->dev.of_node;
pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
if (IS_ERR(pinctrl)) {
@@ -166,6 +213,15 @@ static int ssc_probe(struct platform_device *pdev)
return -ENXIO;
}
+ /* populate platform_data from device tree */
+ if (ssc->pdata && ssc->pdata->use_dma && of) {
+ if (atmel_ssc_get_dma_data(of, &ssc->pdata->dma_slave)) {
+ dev_err(&pdev->dev, "could not get DMA\n");
+ return -EINVAL;
+ }
+ }
+ ssc->pdev->dev.platform_data = &ssc->pdata->dma_slave;
+
/* disable all interrupts */
clk_prepare_enable(ssc->clk);
ssc_writel(ssc->regs, IDR, -1);
diff --git a/include/linux/atmel-ssc.h b/include/linux/atmel-ssc.h
index deb0ae5..80c83ee 100644
--- a/include/linux/atmel-ssc.h
+++ b/include/linux/atmel-ssc.h
@@ -1,12 +1,14 @@
#ifndef __INCLUDE_ATMEL_SSC_H
#define __INCLUDE_ATMEL_SSC_H
+#include
#include
#include
#include
struct atmel_ssc_platform_data {
int use_dma;
+ struct at_dma_slave dma_slave;
};
struct ssc_device {
diff --git a/include/linux/platform_data/dma-atmel.h
b/include/linux/platform_data/dma-atmel.h
index e95f19c..0d8b9d6 100644
--- a/include/linux/platform_data/dma-atmel.h
+++ b/include/linux/platform_data/dma-atmel.h
@@ -44,11 +44,13 @@ struct at_dma_slave {
#defineATC_SRC_H2SEL_SW(0x0 << 9)
#defineATC_SRC_H2SEL_HW(0x1 << 9)
#defineATC_SRC_PER_MSB(h) (ATC_PER_MSB(h) << 10) /* Channel src
rq (most significant bits) */
+#define ATC_GET_SRC_ID(h) h) >> 6) & 0x3U) | ((h) & 0xFU)) /* Retrieve
channel src id */
#defineATC_DST_REP (0x1 << 12) /* Destination Replay
Mod */
#defineATC_DST_H2SEL (0x1 << 13) /* Destination
Handshaking Mod */
#defineATC_DST_H2SEL_SW(0x0 << 13)
#defineATC_DST_H2SEL_HW(0x1 << 13)
#defineATC_DST_PER_MSB(h) (ATC_PER_MSB(h) << 14) /* Channel dst
rq (most significant bits) */
+#define ATC_GET_DST_ID(h) h) >> 10) & 0x3U) | (((h) >> 4) & 0xFU)) /*
Retrieve channel dst id */
#defineATC_SOD (0x1 << 16) /* Stop On Done */
#defineATC_LOCK_IF (0x1 << 20) /* Interface Lock */
#defineATC_LOCK_B (0x1 << 21) /* AHB Bus Lock */
--
1.7.10.4
___
device
Re: [PATCH] of: Specify initrd location using 64-bit
On 07/01/2013 09:59 AM, Geert Uytterhoeven wrote:
> That's actual the original reason: DT has it as 64 bit, and passes it to a
> 32 bit kernel when running in 32 bit mode without PAE.
And I think the DT code should check if the u64 fits in phys_addr_t and
if does not it should write an error message and act like no initrd was
specified (instead of passing "something" to the architecture).
>
> Gr{oetje,eeting}s,
>
> Geert
>
Sebastian
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of: Specify initrd location using 64-bit
On Mon, Jul 1, 2013 at 9:48 AM, Sebastian Andrzej Siewior
wrote:
> On 06/29/2013 01:43 AM, Santosh Shilimkar wrote:
>> Apart from waste of 32bit, what is the other concern you
>> have ?
>
> You pass a u64 as a physical address which is represented in other
> parts of the kernel (for a good reason) by phys_addr_t.
>
>> I really want to converge on this patch because it
>> has been a open ended discussion for quite some time. Does
>> that really break any thing on x86 or your concern is more
>> from semantics of the physical address.
> You want to have your code in so you can continue with your work, that
> is okay. The other two arguments why u64 here is a good thing was "due
> to what I said earlier" and "+1" and I don't have the time to look
> that up.
>
> There should be no problems on x86 if this goes in as it is now.
>
> But think about this: What happens if you boot your ARM device without
> PAE and your initrd is in the upper region? If you are lucky the kernel
> looks at a different place where it also has a read permission, notices
> nothing sane is there, writes a message and continues. And if it is not
> allowed to read? It is clearly the user's fault for booting a non-PAE
> kernel.
That's actual the original reason: DT has it as 64 bit, and passes it to a
32 bit kernel when running in 32 bit mode without PAE.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/4] PCI: Add driver for i.MX6 PCI Express
> This adds a PCI Express port driver for the on-chip PCI Express port
> present on the i.MX6 SoC. It is based on the PCI Express driver available
> in the Freescale BSP.
>
> Signed-off-by: Sean Cross
...
> +++ b/Documentation/devicetree/bindings/pci/imx6q-pcie.txt
> @@ -0,0 +1,20 @@
> +* Freescale i.MX6Q PCI Express bridge
> +
> +Example (i.MX6Q)
> + pcie: pcie@01ffc000 {
> + compatible = "fsl,imx6q-pcie";
> + reg = <0x01ffc000 0x4000>,
> + <0x0100 0x10>,
> + <0x0110 0xe0>,
> + <0x01f0 0xfc000>;
> + interrupts = <0 122 0x04>;
> + clocks = <&clks 186>, <&clks 189>, <&clks 196>,
> + <&clks 198>, <&clks 144>;
> + clock-names = "sata_ref", "pcie_ref_125m", "lvds1_sel",
> + "lvds1", "pcie_axi";
> + power-enable = <&gpio7 12 0>;
> + pcie-reset = <&gpio3 29 0>;
Can this be replaced with regulator/reset API?
> + wake-up = <&gpio3 22 0>;
> + disable-endpoint = <&gpio2 16 0>;
> + };
---
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of: Specify initrd location using 64-bit
On 06/29/2013 01:43 AM, Santosh Shilimkar wrote: > > Sebastian, > > Apart from waste of 32bit, what is the other concern you > have ? You pass a u64 as a physical address which is represented in other parts of the kernel (for a good reason) by phys_addr_t. > I really want to converge on this patch because it > has been a open ended discussion for quite some time. Does > that really break any thing on x86 or your concern is more > from semantics of the physical address. You want to have your code in so you can continue with your work, that is okay. The other two arguments why u64 here is a good thing was "due to what I said earlier" and "+1" and I don't have the time to look that up. There should be no problems on x86 if this goes in as it is now. But think about this: What happens if you boot your ARM device without PAE and your initrd is in the upper region? If you are lucky the kernel looks at a different place where it also has a read permission, notices nothing sane is there, writes a message and continues. And if it is not allowed to read? It is clearly the user's fault for booting a non-PAE kernel. > > Thanks for help. > > Regards, > Santosh Sebastian ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/4] Add PCI Express to i.MX6
This patchset adds a PCI Express driver for the Freescale i.MX6 series of SoCs. It is based on the BSP driver, available from Freescale athttp://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git This patchset does the following: 1) Add general-purpose LVDS clocks to drive the bus 2) Enable PCI Express on ARM 3) Add the pcie-imx driver 4) Add device tree bindings for imx6qdl.dtsi Sean Cross (4): ARM i.MX6q: Add descriptors for LVDS clocks ARM: Enable PCI Express on ARM PCI: Add driver for i.MX6 PCI Express ARM i.MX6: Add PCI Express to device tree .../devicetree/bindings/clock/imx6q-clock.txt |4 + .../devicetree/bindings/pci/imx6q-pcie.txt | 20 + arch/arm/Kconfig |2 + arch/arm/boot/dts/imx6qdl.dtsi | 12 + arch/arm/mach-imx/Kconfig |1 + arch/arm/mach-imx/clk-imx6q.c | 13 +- drivers/pci/pcie/Kconfig | 10 + drivers/pci/pcie/Makefile |2 + drivers/pci/pcie/pcie-imx.c| 1049 9 files changed, insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/pci/imx6q-pcie.txt create mode 100644 drivers/pci/pcie/pcie-imx.c -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/4] ARM i.MX6q: Add descriptors for LVDS clocks
There are two general-purpose LVDS clocks available on the i.MX6. Add
clock descriptors for both of these clocks, as well as selectors to be
able to generate various external signals.
Signed-off-by: Sean Cross
---
.../devicetree/bindings/clock/imx6q-clock.txt |4
arch/arm/mach-imx/clk-imx6q.c | 13 +++--
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
index 6deb6fd..b2b4acb 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
@@ -208,6 +208,10 @@ clocks and IDs.
pll4_post_div 193
pll5_post_div 194
pll5_video_div 195
+ lvds1_sel 196
+ lvds2_sel 197
+ lvds1 198
+ lvds2 199
Examples:
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 4e3148c..f0c0591 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -204,7 +204,9 @@ static const char *vdo_axi_sels[] = { "axi", "ahb", };
static const char *vpu_axi_sels[] = { "axi", "pll2_pfd2_396m",
"pll2_pfd0_352m", };
static const char *cko1_sels[] = { "pll3_usb_otg", "pll2_bus", "pll1_sys",
"pll5_video_div",
"dummy", "axi", "enfc", "ipu1_di0",
"ipu1_di1", "ipu2_di0",
- "ipu2_di1", "ahb", "ipg", "ipg_per",
"ckil", "pll4_post_div", };
+ "ipu2_di1", "ahb", "ipg", "ipg_per",
"ckil", "pll4_audio", };
+static const char *lvds1_sels[] = { "dummy", "dummy", "dummy", "dummy",
"dummy", "dummy", "pll4_audio", "pll5_video", "pll8_mlb", "enet_ref",
"pcie_ref", "sata_ref", "dummy", "dummy", "dummy", "dummy", "dummy", "dummy",
"dummy", "lvds1", "lvds2", };
+static const char *lvds2_sels[] = { "dummy", "dummy", "dummy", "dummy",
"dummy", "dummy", "pll4_audio", "pll5_video", "pll8_mlb", "enet_ref",
"pcie_ref", "sata_ref", "dummy", "dummy", "dummy", "dummy", "dummy", "dummy",
"dummy", "lvds1", "lvds2", };
enum mx6q_clks {
dummy, ckil, ckih, osc, pll2_pfd0_352m, pll2_pfd1_594m, pll2_pfd2_396m,
@@ -238,7 +240,8 @@ enum mx6q_clks {
pll4_audio, pll5_video, pll8_mlb, pll7_usb_host, pll6_enet, ssi1_ipg,
ssi2_ipg, ssi3_ipg, rom, usbphy1, usbphy2, ldb_di0_div_3_5,
ldb_di1_div_3_5,
sata_ref, sata_ref_100m, pcie_ref, pcie_ref_125m, enet_ref,
usbphy1_gate,
- usbphy2_gate, pll4_post_div, pll5_post_div, pll5_video_div, clk_max
+ usbphy2_gate, pll4_post_div, pll5_post_div, pll5_video_div,
+ lvds1_sel, lvds2_sel, lvds1, lvds2, clk_max
};
static struct clk *clk[clk_max];
@@ -360,6 +363,12 @@ int __init mx6q_clocks_init(void)
clk[pll5_post_div] = clk_register_divider_table(NULL, "pll5_post_div",
"pll5_video", CLK_SET_RATE_PARENT, base + 0xa0, 19, 2, 0, post_div_table,
&imx_ccm_lock);
clk[pll5_video_div] = clk_register_divider_table(NULL,
"pll5_video_div", "pll5_post_div", CLK_SET_RATE_PARENT, base + 0x170, 30, 2, 0,
video_div_table, &imx_ccm_lock);
+ clk[lvds1_sel]= imx_clk_mux("lvds1_sel",base + 0x160,
0, 5, lvds1_sels, ARRAY_SIZE(lvds1_sels));
+ clk[lvds2_sel]= imx_clk_mux("lvds2_sel",base + 0x160,
0, 5, lvds2_sels, ARRAY_SIZE(lvds2_sels));
+
+ clk[lvds1] = imx_clk_gate("lvds1", "dummy", base + 0x160, 10);
+ clk[lvds2] = imx_clk_gate("lvds2", "dummy", base + 0x160, 11);
+
np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-ccm");
base = of_iomap(np, 0);
WARN_ON(!base);
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/4] PCI: Add driver for i.MX6 PCI Express
This adds a PCI Express port driver for the on-chip PCI Express port
present on the i.MX6 SoC. It is based on the PCI Express driver available
in the Freescale BSP.
Signed-off-by: Sean Cross
---
.../devicetree/bindings/pci/imx6q-pcie.txt | 20 +
arch/arm/mach-imx/Kconfig |1 +
drivers/pci/pcie/Kconfig | 10 +
drivers/pci/pcie/Makefile |2 +
drivers/pci/pcie/pcie-imx.c| 1049
5 files changed, 1082 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/imx6q-pcie.txt
create mode 100644 drivers/pci/pcie/pcie-imx.c
diff --git a/Documentation/devicetree/bindings/pci/imx6q-pcie.txt
b/Documentation/devicetree/bindings/pci/imx6q-pcie.txt
new file mode 100644
index 000..2dc9eae
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/imx6q-pcie.txt
@@ -0,0 +1,20 @@
+* Freescale i.MX6Q PCI Express bridge
+
+Example (i.MX6Q)
+ pcie: pcie@01ffc000 {
+ compatible = "fsl,imx6q-pcie";
+ reg = <0x01ffc000 0x4000>,
+ <0x0100 0x10>,
+ <0x0110 0xe0>,
+ <0x01f0 0xfc000>;
+ interrupts = <0 122 0x04>;
+ clocks = <&clks 186>, <&clks 189>, <&clks 196>,
+<&clks 198>, <&clks 144>;
+ clock-names = "sata_ref", "pcie_ref_125m", "lvds1_sel",
+ "lvds1", "pcie_axi";
+ power-enable = <&gpio7 12 0>;
+ pcie-reset = <&gpio3 29 0>;
+ wake-up = <&gpio3 22 0>;
+ disable-endpoint = <&gpio2 16 0>;
+ };
+
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index ba44328..cad4e5a 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -811,6 +811,7 @@ config SOC_IMX6Q
select PL310_ERRATA_588369 if CACHE_PL310
select PL310_ERRATA_727915 if CACHE_PL310
select PL310_ERRATA_769419 if CACHE_PL310
+ select MIGHT_HAVE_PCI
select PM_OPP if PM
help
diff --git a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig
index 569f82f..d1d70db 100644
--- a/drivers/pci/pcie/Kconfig
+++ b/drivers/pci/pcie/Kconfig
@@ -83,3 +83,13 @@ endchoice
config PCIE_PME
def_bool y
depends on PCIEPORTBUS && PM_RUNTIME
+
+#
+# Platform driver for i.MX6
+#
+config PCIE_IMX
+bool "Support for i.MX6"
+depends on SOC_IMX6Q
+help
+ Enable support for the 1x PCI Express bus on the Freescale i.MX6
+depends on PCIEPORTBUS && PM_RUNTIME
diff --git a/drivers/pci/pcie/Makefile b/drivers/pci/pcie/Makefile
index 00c62df..5393d21 100644
--- a/drivers/pci/pcie/Makefile
+++ b/drivers/pci/pcie/Makefile
@@ -14,3 +14,5 @@ obj-$(CONFIG_PCIEPORTBUS) += pcieportdrv.o
obj-$(CONFIG_PCIEAER) += aer/
obj-$(CONFIG_PCIE_PME) += pme.o
+
+obj-$(CONFIG_PCIE_IMX) += pcie-imx.o
diff --git a/drivers/pci/pcie/pcie-imx.c b/drivers/pci/pcie/pcie-imx.c
new file mode 100644
index 000..664679e
--- /dev/null
+++ b/drivers/pci/pcie/pcie-imx.c
@@ -0,0 +1,1049 @@
+/*
+ * drivers/pci/pcie/pcie-imx.c
+ *
+ * PCIe host controller driver for IMX6 SOCs
+ *
+ * Copyright (C) 2012 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * Code originally taken from Freescale linux-2.6.35 BSP.
+ *
+ * Other bits taken from arch/arm/mach-dove/pcie.c
+ *
+ * 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.
+
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+
+/* IOMUXC */
+#define IOMUXC_GPR0 (0x00)
+#define IOMUXC_GPR1 (0x04)
+#define IOMUXC_GPR2 (0x08)
+#define IOMUXC_GPR3 (0x0C)
+#define IOMUXC_GPR4 (0x10)
+#define IOMUXC_GPR5 (0x14)
+#define IOMUXC_GPR6 (0x18)
+#define IOMUXC_GPR7 (0x1C)
+#define IOMUXC_GPR8 (0x20)
+#define IOMUXC_GPR9 (0x24)
+#define IOMUXC_GPR10(0x28)
+#define IOMUXC_GPR11
[PATCH 2/4] ARM: Enable PCI Express on ARM
Some ARM devices have PCI Express hardware, and should be able to take advantage of PCI Express code present in the common driver files. Enable PCI Express on ARM, when PCI is available. Signed-off-by: Sean Cross --- arch/arm/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 136f263..2f51f13 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1418,6 +1418,8 @@ config PCI_HOST_ITE8152 source "drivers/pci/Kconfig" +source "drivers/pci/pcie/Kconfig" + source "drivers/pcmcia/Kconfig" endmenu -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 4/4] ARM i.MX6: Add PCI Express to device tree
Add a PCI Express port to the i.MX6 device tree using interrupts, clocks,
and memory ranges appropriate for the device.
Signed-off-by: Sean Cross
---
arch/arm/boot/dts/imx6qdl.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 9e8296e..4b5facb 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -654,6 +654,18 @@
status = "disabled";
};
+ pcie: pcie@01ffc000 {
+ compatible = "fsl,imx6q-pcie";
+ reg = <0x01ffc000 0x4000>,
+ <0x0100 0x10>,
+ <0x0110 0xe0>,
+ <0x01f0 0xfc000>;
+ interrupts = <0 122 0x04>;
+ clocks = <&clks 186>, <&clks 189>, <&clks 196>,
<&clks 198>, <&clks 144>;
+ clock-names = "sata_ref", "pcie_ref_125m",
"lvds1_sel", "lvds1", "pcie_axi";
+ status = "disabled";
+ };
+
mlb@0218c000 {
reg = <0x0218c000 0x4000>;
interrupts = <0 53 0x04 0 117 0x04 0 126 0x04>;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] ARM: dts: mx53qsb: Enable VPU support
Hi Matt,
[Cc: devicetree-discuss@lists.ozlabs.org]
Am Freitag, den 28.06.2013, 23:49 -0500 schrieb Matt Sealey:
> On Fri, Jun 28, 2013 at 5:49 PM, Fabio Estevam wrote:
> > From: Fabio Estevam
> >
> > Enable Video Processing Unit (VPU) support.
> >
> > Signed-off-by: Fabio Estevam
> > ---
> > Depends on Philipp Zabel's patch:
> > [PATCH] ARM: dts: add sram for imx53 and imx6q
> >
> > Philipp,
> >
> > I tried using the original mx53 vpu firmware that comes with the FSL BSP,
> > but it
> > failed to load:
> >
> > coda 63ff4000.vpu: firmware get command error
> > coda 63ff4000.vpu: HW initialization failed
> >
> > Any suggestions?
> >
> > Thanks!
> >
> > arch/arm/boot/dts/imx53-qsb.dts | 4
> > arch/arm/boot/dts/imx53.dtsi| 10 ++
> > 2 files changed, 14 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx53-qsb.dts
> > b/arch/arm/boot/dts/imx53-qsb.dts
> > index 512a1f6..eedd27e 100644
> > --- a/arch/arm/boot/dts/imx53-qsb.dts
> > +++ b/arch/arm/boot/dts/imx53-qsb.dts
> > @@ -297,6 +297,10 @@
> > status = "okay";
> > };
> >
> > +&vpu {
> > + status = "okay";
> > +};
> > +
> > &usbh1 {
> > status = "okay";
> > };
> > diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
> > index 3def46f..f94d4e5 100644
> > --- a/arch/arm/boot/dts/imx53.dtsi
> > +++ b/arch/arm/boot/dts/imx53.dtsi
> > @@ -1086,6 +1086,16 @@
> > crtcs = <&ipu 1>;
> > status = "disabled";
> > };
> > +
> > + vpu: vpu@63ff4000 {
> > + compatible = "fsl,imx53-vpu";
> > + reg = <0x63ff4000 0x1000>;
> > + interrupts = <9>;
> > + clocks = <&clks 63>, <&clks 63>;
> > + clock-names = "per", "ahb";
> > + iram = <&ocram>;
> > + status = "disabled";
> > + };
> > };
> >
> > ocram: ocram@f800 {
>
> Nitpick: what I see here around enabling the VPU driver is;
>
> * A property called iram
> * ... that references a node called ocram
> * ... which is coincidentally driven by a driver called sram
>
> Could we make up our minds as to what to call it? Something generic
> that's potentially not i.MX-specific (since it does change over the
> models, and it may not be technically SRAM..) that gets used
> everywhere and belies it's purpose rather than naming a particular
> technology, or particular IP core documentation if it changes a lot?
I'd be in favor of changing
- ocram: ocram@f800 {
+ ocram: sram@f800 {
but it is very convenient to have the IP vendor's creative name in
there, too, if I have to look it up in the reference manual.
>From point of view of the VPU, the SRAM is a more local memory, in most
implementations connected via a dedicated AXI bus to avoid load on the
main memory bus.
regards
Philipp
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V3 3/3] video: exynos_dp: Use the generic PHY driver
On Monday, July 01, 2013 3:28 PM, Kishon Vijay Abraham I wrote:
>
> Hi,
>
> On Monday 01 July 2013 10:54 AM, Jingoo Han wrote:
> > Use the generic PHY API instead of the platform callback to control
> > the DP PHY. The 'phy_label' field is added to the platform data
> > structure to allow PHY lookup on non-dt platforms.
> >
> > Signed-off-by: Jingoo Han
> > Acked-by: Felipe Balbi
> > ---
> > .../devicetree/bindings/video/exynos_dp.txt| 23 +---
> > drivers/video/exynos/exynos_dp_core.c | 118
> > ++--
> > drivers/video/exynos/exynos_dp_core.h |2 +
> > include/video/exynos_dp.h |6 +-
> > 4 files changed, 21 insertions(+), 128 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
> b/Documentation/devicetree/bindings/video/exynos_dp.txt
> > index 84f10c1..71645dc 100644
> > --- a/Documentation/devicetree/bindings/video/exynos_dp.txt
> > +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
> > @@ -1,17 +1,6 @@
> > The Exynos display port interface should be configured based on
> > the type of panel connected to it.
> >
> > -We use two nodes:
> > - -dp-controller node
> > - -dptx-phy node(defined inside dp-controller node)
> > -
> > -For the DP-PHY initialization, we use the dptx-phy node.
> > -Required properties for dptx-phy:
> > - -reg:
> > - Base address of DP PHY register.
> > - -samsung,enable-mask:
> > - The bit-mask used to enable/disable DP PHY.
> > -
> > For the Panel initialization, we read data from dp-controller node.
> > Required properties for dp-controller:
> > -compatible:
> > @@ -25,6 +14,10 @@ Required properties for dp-controller:
> > from common clock binding: handle to dp clock.
> > -clock-names:
> > from common clock binding: Shall be "dp".
> > + -phys:
> > + from general phy binding: the phandle for the PHY device.
> > + -phy-names:
> > + from general phy binding: Should be "dp".
> > -interrupt-parent:
> > phandle to Interrupt combiner node.
> > -samsung,color-space:
> > @@ -67,12 +60,8 @@ SOC specific portion:
> > interrupt-parent = <&combiner>;
> > clocks = <&clock 342>;
> > clock-names = "dp";
> > -
> > - dptx-phy {
> > - reg = <0x10040720>;
> > - samsung,enable-mask = <1>;
> > - };
> > -
> > + phys = <&dp_phy>;
> > + phy-names = "dp";
> > };
> >
> > Board Specific portion:
> > diff --git a/drivers/video/exynos/exynos_dp_core.c
> > b/drivers/video/exynos/exynos_dp_core.c
> > index 12bbede..bac515b 100644
> > --- a/drivers/video/exynos/exynos_dp_core.c
> > +++ b/drivers/video/exynos/exynos_dp_core.c
> > @@ -19,6 +19,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> >
> > @@ -960,84 +961,15 @@ static struct exynos_dp_platdata
> > *exynos_dp_dt_parse_pdata(struct device *dev)
> > return ERR_PTR(-EINVAL);
> > }
> >
> > - return pd;
> > -}
> > -
> > -static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
> > -{
> > - struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
> > - u32 phy_base;
> > - int ret = 0;
> > -
> > - dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
> > - if (!dp_phy_node) {
> > - dev_err(dp->dev, "could not find dptx-phy node\n");
> > - return -ENODEV;
> > - }
> > -
> > - if (of_property_read_u32(dp_phy_node, "reg", &phy_base)) {
> > - dev_err(dp->dev, "failed to get reg for dptx-phy\n");
> > - ret = -EINVAL;
> > - goto err;
> > - }
> > -
> > - if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
> > - &dp->enable_mask)) {
> > - dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
> > - ret = -EINVAL;
> > - goto err;
> > - }
> > -
> > - dp->phy_addr = ioremap(phy_base, SZ_4);
> > - if (!dp->phy_addr) {
> > - dev_err(dp->dev, "failed to ioremap dp-phy\n");
> > - ret = -ENOMEM;
> > - goto err;
> > - }
> > -
> > -err:
> > - of_node_put(dp_phy_node);
> > -
> > - return ret;
> > -}
> > -
> > -static void exynos_dp_phy_init(struct exynos_dp_device *dp)
> > -{
> > - u32 reg;
> > -
> > - reg = __raw_readl(dp->phy_addr);
> > - reg |= dp->enable_mask;
> > - __raw_writel(reg, dp->phy_addr);
> > -}
> > -
> > -static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
> > -{
> > - u32 reg;
> > + pd->phy_label = "dp";
>
> Felipe had a comment to change the label to *display-port* no?
No, I don't think so. :)
I would like to use 'dp'.
Best regards,
Jingoo Han
>
> Thanks
> Kishon
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/dev
