[PATCH] clk: exynos5250: Fix parent clock for sclk_mmc{0,1,2,3}
commit 688f7d8c9fef ("clk: exynos5250: Fix divider values for
sclk_mmc{0,1,2,3}") incorrectly sets the divider for sclk_mmc{0,1,2,3}
to fix the wrong clock value. Though this fixed issue with Arndale,
it created regressions for other boards like Snow.
On Exynos5250, sclk_mmc is generated like below (as per the clock
names in drivers/clk/samsung/clk-exynos5250.c)
mout_group1_p ==> mout_mmc ==>
div_mmc ==> div_mmc_pre => sclk_mmc
Earlier div_mmc was set as the parent for sclk_mmc, hence
div_mmc_pre was not getting referred in kernel code and depending
on its value set during preboot, sclk_mmc value was different for
various boards.
Setting the correct clock generation path should fix the issues
reported in above referenced commit. The changes committed during the
earlier patch has also been reverted here.
Signed-off-by: Tushar Behera
CC: Doug Anderson
---
Doug,
Would you please test whether this patch works for Snow?
drivers/clk/samsung/clk-exynos5250.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c
index 7290faa..bb54606 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -276,10 +276,10 @@ struct samsung_div_clock exynos5250_div_clks[] __initdata
= {
DIV(none, "div_pcm0", "sclk_audio0", DIV_MAU, 4, 8),
DIV(none, "div_sata", "mout_sata", DIV_FSYS0, 20, 4),
DIV(none, "div_usb3", "mout_usb3", DIV_FSYS0, 24, 4),
- DIV(none, "div_mmc0", "mout_mmc0", DIV_FSYS1, 8, 8),
- DIV(none, "div_mmc1", "mout_mmc1", DIV_FSYS1, 24, 8),
- DIV(none, "div_mmc2", "mout_mmc2", DIV_FSYS2, 8, 8),
- DIV(none, "div_mmc3", "mout_mmc3", DIV_FSYS2, 24, 8),
+ DIV(none, "div_mmc0", "mout_mmc0", DIV_FSYS1, 0, 4),
+ DIV(none, "div_mmc1", "mout_mmc1", DIV_FSYS1, 16, 4),
+ DIV(none, "div_mmc2", "mout_mmc2", DIV_FSYS2, 0, 4),
+ DIV(none, "div_mmc3", "mout_mmc3", DIV_FSYS2, 16, 4),
DIV(none, "div_uart0", "mout_uart0", DIV_PERIC0, 0, 4),
DIV(none, "div_uart1", "mout_uart1", DIV_PERIC0, 4, 4),
DIV(none, "div_uart2", "mout_uart2", DIV_PERIC0, 8, 4),
@@ -421,13 +421,13 @@ struct samsung_gate_clock exynos5250_gate_clks[]
__initdata = {
SRC_MASK_DISP1_0, 20, 0, 0),
GATE(sclk_audio0, "sclk_audio0", "div_audio0",
SRC_MASK_MAU, 0, CLK_SET_RATE_PARENT, 0),
- GATE(sclk_mmc0, "sclk_mmc0", "div_mmc0",
+ GATE(sclk_mmc0, "sclk_mmc0", "div_mmc_pre0",
SRC_MASK_FSYS, 0, CLK_SET_RATE_PARENT, 0),
- GATE(sclk_mmc1, "sclk_mmc1", "div_mmc1",
+ GATE(sclk_mmc1, "sclk_mmc1", "div_mmc_pre1",
SRC_MASK_FSYS, 4, CLK_SET_RATE_PARENT, 0),
- GATE(sclk_mmc2, "sclk_mmc2", "div_mmc2",
+ GATE(sclk_mmc2, "sclk_mmc2", "div_mmc_pre2",
SRC_MASK_FSYS, 8, CLK_SET_RATE_PARENT, 0),
- GATE(sclk_mmc3, "sclk_mmc3", "div_mmc3",
+ GATE(sclk_mmc3, "sclk_mmc3", "div_mmc_pre3",
SRC_MASK_FSYS, 12, CLK_SET_RATE_PARENT, 0),
GATE(sclk_sata, "sclk_sata", "div_sata",
SRC_MASK_FSYS, 24, CLK_SET_RATE_PARENT, 0),
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] thermal:exynos4: Thermal Measurement Unit fixes for Samsung SoCs
Hi Kukjin, > On 04/20/13 01:38, Lukasz Majewski wrote: > > This patch series provide various fixes for TMU block. > > Namely, support for common clock framework and proper regulator > > VDD_TS has been added. > > Moreover device tree definitions and documentation entry are now in > > place. > > > > Lukasz Majewski (6): > >clk:exynos4:TMU Thermal Measurement Unit clock added to common > > clock framework > >thermal:exynos4: TMU Common clock framework support for TMU > > (Thermal Monitoring Unit) > >thermal:exynos4: TMU device tree support for Exynos4412 targets > >thermal: Support for TMU regulator defined at device tree > >thermal:exynos4: Enable support for Exynos4412 SoCs > >thermal:exynos4: Add documentation for Exynos SoC thermal > > bindings > > > > .../devicetree/bindings/clock/exynos4-clock.txt|1 + > > .../devicetree/bindings/thermal/exynos-thermal.txt | 22 > > +++ arch/arm/boot/dts/exynos4x12.dtsi | > > 10 + drivers/clk/samsung/clk-exynos4.c |6 > > ++- drivers/thermal/exynos_thermal.c | 41 > > +++- 5 files changed, 70 insertions(+), 10 > > deletions(-) create mode 100644 > > Documentation/devicetree/bindings/thermal/exynos-thermal.txt > > > Lukasz, please address comments from ml. > Ok. I'm going to prepare v2 > Others looks good to me. > > - Kukjin -- Best regards, Lukasz Majewski Samsung R&D Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] thermal:exynos4: Add documentation for Exynos SoC thermal bindings
Hi Sachin, > Hi Lukasz, > > Thanks for adding this. Some comments inline. > > On 19 April 2013 22:08, Lukasz Majewski > wrote: > > Proper description for Exynos4 bindings added to > > Documentation/devicetree/ bindings > > > > Signed-off-by: Lukasz Majewski > > Signed-off-by: Kyungmin Park > > --- > > .../devicetree/bindings/thermal/exynos-thermal.txt | 22 > > 1 file changed, 22 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/thermal/exynos-thermal.txt > > > > diff --git > > a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt > > b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt new > > file mode 100644 index 000..e994e1e --- /dev/null > > +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt > > @@ -0,0 +1,22 @@ > > +* Exynos Thermal > > How about "Exynos Thermal Management Unit (TMU)"? > > > + > > +Required properties: > > +- compatible : "samsung,exynos4412-tmu" > Should be one of the following: > "samsung,exynos4210-tmu" > "samsung,exynos4412-tmu" So all thee names shall be added? Right? > "samsung,exynos5250-tmu" > > > > +- interrupts-parent : The phandle for the interrupt controller > > s/interrupts-parent /interrupt-parent > > > > +- reg : Address range of the thermal registers > > +- interrupts : Should contain interrupt for thermal system > > +- clocks : The main clock for TMU device > > +- clocks-names : Thermal system clock name > > s/clocks-names /clock-names > You may also choose to add "from common clock binding" for clocks and > clock-names properties above. > > > +- status : Initial state of the device > You may remove this as it is quite obvious now. Even if you want to > retain this, it should be under 'Optional properties:' > > Ok, I will correct those names. -- Best regards, Lukasz Majewski Samsung R&D Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] thermal: Support for TMU regulator defined at device tree
Hi Eduardo,
> On 19-04-2013 12:38, Lukasz Majewski wrote:
> > TMU probe function now checks for a device tree defined regulator.
> > For compatibility reasons it is allowed to probe driver even without
> > this regulator defined.
> >
> > Signed-off-by: Lukasz Majewski
> > Signed-off-by: Kyungmin Park
> > ---
> > drivers/thermal/exynos_thermal.c | 19 +++
> > 1 file changed, 19 insertions(+)
> >
> > diff --git a/drivers/thermal/exynos_thermal.c
> > b/drivers/thermal/exynos_thermal.c index ba6094c..e922fa4 100644
> > --- a/drivers/thermal/exynos_thermal.c
> > +++ b/drivers/thermal/exynos_thermal.c
> > @@ -38,6 +38,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> >
> > @@ -119,6 +120,8 @@
> >
> > #define EXYNOS_ZONE_COUNT 3
> >
> > +#define EXYNOS_TMU_REGULATOR "vdd_ts"
> > +
> > struct exynos_tmu_data {
> > struct exynos_tmu_platform_data *pdata;
> > struct resource *mem;
> > @@ -944,6 +947,7 @@ static int exynos_tmu_probe(struct
> > platform_device *pdev) {
> > struct exynos_tmu_data *data;
> > struct exynos_tmu_platform_data *pdata =
> > pdev->dev.platform_data;
> > + struct regulator *reg;
> > int ret, i;
> >
> > if (!pdata)
> > @@ -953,6 +957,21 @@ static int exynos_tmu_probe(struct
> > platform_device *pdev) dev_err(&pdev->dev, "No platform init data
> > supplied.\n"); return -ENODEV;
> > }
> > +
> > + reg = regulator_get(&pdev->dev, EXYNOS_TMU_REGULATOR);
> > + if (!IS_ERR(reg)) {
> > + ret = regulator_enable(reg);
> > + if (ret) {
> > + dev_err(&pdev->dev, "Regulator %s not
> > enabled.\n",
> > + EXYNOS_TMU_REGULATOR);
> > + return ret;
> > + }
> > + } else {
> > + dev_info(&pdev->dev,
> > +"Regulator %s not defined at device
> > tree.\n",
> > +EXYNOS_TMU_REGULATOR);
> Maybe a dev_warn would fit better?
This is a bit tricky. I first wanted to return -ENODEV when regulator
is not available. Then I understood, that some other SoCs (e.g.
Exynos5) will not work.
The info here shall give a clear warn signal, that providing a
regulator for VDD_TS is crucial (since by default it can be connected
to other PMIC outputs and when other device puts down this regulator
the TMU will crash and shut down a system).
>
> > + }
> > +
> > data = devm_kzalloc(&pdev->dev, sizeof(struct
> > exynos_tmu_data), GFP_KERNEL);
> > if (!data) {
> >
--
Best regards,
Lukasz Majewski
Samsung R&D Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] thermal:exynos4: TMU device tree support for Exynos4412 targets
Hi Sachin,
> Hi Lukasz,
>
> On 19 April 2013 22:08, Lukasz Majewski
> wrote:
> > Device tree support for TMU at Exynos4x12 targets.
> >
> > Signed-off-by: Lukasz Majewski
> > Signed-off-by: Kyungmin Park
>
> nit: Subject for these kind of patches should start with "ARM:
> dts: ..."
>
Ok, I will correct that.
> Otherwise looks good to me.
Good :-)
> > ---
> > arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
> > b/arch/arm/boot/dts/exynos4x12.dtsi index e3380a7..ee920b3 100644
> > --- a/arch/arm/boot/dts/exynos4x12.dtsi
> > +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> > @@ -79,4 +79,14 @@
> > interrupts = <0 89 0>;
> > status = "disabled";
> > };
> > +
> > + tmu@100C {
> > + compatible = "samsung,exynos4412-tmu";
> > + interrupt-parent = <&combiner>;
> > + reg = <0x100C 0x100>;
> > + interrupts = <2 4>;
> > + clocks = <&clock 383>;
> > + clock-names = "tmu_apbif";
> > + status = "disabled";
> > + };
> > };
> > --
> > 1.7.10.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-samsung-soc" in the body of a message to
> > majord...@vger.kernel.org More majordomo info at
> > http://vger.kernel.org/majordomo-info.html
>
>
>
--
Best regards,
Lukasz Majewski
Samsung R&D Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] thermal:exynos4: TMU device tree support for Exynos4412 targets
Hi Eduardo,
> On 19-04-2013 12:38, Lukasz Majewski wrote:
> > Device tree support for TMU at Exynos4x12 targets.
> >
> > Signed-off-by: Lukasz Majewski
> > Signed-off-by: Kyungmin Park
> > ---
> > arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
> > b/arch/arm/boot/dts/exynos4x12.dtsi index e3380a7..ee920b3 100644
> > --- a/arch/arm/boot/dts/exynos4x12.dtsi
> > +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> > @@ -79,4 +79,14 @@
> > interrupts = <0 89 0>;
> > status = "disabled";
> > };
> > +
> > + tmu@100C {
> > + compatible = "samsung,exynos4412-tmu";
>
>
> Is this one already documented?
The last commit in the series provide a documentation.
>
> > + interrupt-parent = <&combiner>;
> > + reg = <0x100C 0x100>;
> > + interrupts = <2 4>;
> > + clocks = <&clock 383>;
> > + clock-names = "tmu_apbif";
> > + status = "disabled";
> > + };
> > };
> >
--
Best regards,
Lukasz Majewski
Samsung R&D Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] thermal:exynos4: TMU Common clock framework support for TMU (Thermal Monitoring Unit)
Hi Sachin,
> On 19 April 2013 22:08, Lukasz Majewski
> wrote:
> > This patch modifies exynos_thermal.c file to use
> > clk_disable_unprepare() and clk_prepare_enable() instead of
> > clk_{enable|disable}.
> >
> > Signed-off-by: Lukasz Majewski
> > Signed-off-by: Kyungmin Park
> > ---
>
> I have already submitted a similar patch for this:
> http://permalink.gmane.org/gmane.linux.power-management.general/33310
>
>
Thanks for pointing to the correct patch.
However, I've got a question:
The patch only changes clock names at exynos_tmu_{probe|remove}.
Correct me if I'm wrong, but shouldn't we also change clock_enable to
clk_prepare_enable at exynos_tmu_read()? (Are we guaranteed, that we
will NOT sleep there?)
--
Best regards,
Lukasz Majewski
Samsung R&D Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/10] ARM: exynos multiplatform series, part 1
On 22 April 2013 18:42, Arnd Bergmann wrote: > On Monday 22 April 2013, Sachin Kamat wrote: >> >> With this branch now available (merged) in linux-next (20130422), >> looks like exynos4 DT support is broken on it. Tested on Origen 4210 >> and 4412 and I get the following warnings on 4412 Origen board with >> exynos_defconfig (Note that clocks are all 0). However, it boots fine >> on Arndale board. > > I think this issue should be fixed with the patch that Thomas Abraham > just sent. Thomas, can you confirm? Boot tested Origen 4210, 4412 and Arndale boards after applying Thomas Abraham's chip-id dt support patches. They all boot fine. However I could not see multiplatform support for Exynos in exynos_defconfig (i.e., CONFIG_ARCH_EXYNOS and CONFIG_ARCH_MULTIPLATFORM are not set together). This was available in your 'samsung/exynos-multiplatform' branch. Has this been disabled in next? --- With warm regards, Sachin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: exynos5250: Fix divider values for sclk_mmc{0,1,2,3}
On 04/22/2013 11:10 PM, Olof Johansson wrote:
> Hi,
>
> On Tue, Apr 16, 2013 at 12:35 PM, Doug Anderson wrote:
>> Hi,
>>
>> On Mon, Apr 8, 2013 at 12:22 AM, Kukjin Kim wrote:
>>> Mike Turquette wrote:
Quoting Tushar Behera (2013-04-02 01:20:40)
> In legacy setup, sclk_mmc{0,1,2,3} used PRE_RATIO bit-field (8-bit wide)
> instead of RATIO bit-field (4-bit wide) for dividing clock rate.
>
> With current common clock setup, we are using RATIO bit-field which
> is creating FIFO read errors while accessing eMMC. Changing over to
> use PRE_RATIO bit-field fixes this issue.
>
> dwmmc_exynos 1220.dwmmc0: data FIFO error (status=8020)
> mmcblk0: error -5 transferring data, sector 1, nr 7, cmd response 0x900,
card status 0x0
> end_request: I/O error, dev mmcblk0, sector 1
>
> Signed-off-by: Tushar Behera
> CC: Thomas Abraham
I guess this will be applied through the samsung tree, so:
Acked-by: Mike Turquette
>>> Thanks, applied.
>>
>> I haven't yet had time to dig / track down why, but this patch totally
>> messes up access to the eMMC on the ARM Chromebook (exynos5250-snow).
>> I suddenly start getting FIFO errors like you show above. When I
>> revert your change then I'm all happy.
>>
>> Perhaps I need a device tree setting change as well? I always forget
>> how the "samsung,dw-mshc-ciu-div" / "samsung,dw-mshc-sdr-timing"
>> properties work...
>>
>> For the short term I'm going to revert locally since I've got a few
>> other things to do over the next few days. If nobody else gets around
>> to it then I'll try to find time to dig further.
>
> Unless I hear differently within 24 hours, I am going to revert this
> in arm-soc (since that is where it is merged right now).
>
I will have a look at it today.
> It is obviously causing regressions on existing platforms. I am _NOT_
> happy to see dead silence about this for 6 days. Tushar??
>
Apologies.
>
>
> -Olof
>
--
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/3] of/pci: Provide common support for PCI DT parsing
On Mon, Apr 22, 2013 at 12:53:43PM -0400, Jason Cooper wrote: > On Mon, Apr 22, 2013 at 11:41:32AM +0100, Andrew Murray wrote: > > This patchset factors out duplicated code associated with parsing PCI > > DT "ranges" properties across the architectures and introduces a > > "ranges" parser. This parser "of_pci_range_parser" can be used directly > > by ARM host bridge drivers enabling them to obtain ranges from device > > trees. > > > > I've included the Reviewed-by, Tested-by and Acked-by's received from > > v5/v6/v7 > > in this patchset, earlier versions of this patchset (v3) have been > > tested-by: > > > > Thierry Reding > > Jingoo Han > > > > I've tested that this patchset builds and runs on ARM and that it builds on > > PowerPC, x86_64 and MIPS. > > Andrew, > > Unfortunately, the mvebu/drivers branch containing your series had to be > dropped from arm-soc for v3.10. This was not due to your series, but > since arm-soc's granularity is branches, your series was caught in the > drop. > > As the mvebu-pcie driver is now v3.11 material, I have taken the > opportunity to upgrade from your v7 patchset to v8. You can find the > whole branch at mvebu-next/pcie. > > mvebu-next/pcie *will* be rebased onto v3.9 once it drops. Several > dependencies will be removed (since they will have been merged into > v3.9). s/v3.9/v3.10-rc1/g :) > Once the rebase is done, I'll send a pull request to Arnd and Olof so we > can get as many cycles on -next as possible. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: dts: exynos4210: Add basic dts file for universal_c210 board
On Monday 15 April 2013, Tomasz Figa wrote: > > This patch adds basic device tree sources for Universal C210 board. > > Currently support includes: > - eMMC > - serial > - max8952 and max8998 voltage regulators. > - gpio-keys > > More support will be added in further patches. > > Signed-off-by: Tomasz Figa Acked-by: Arnd Bergmann -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] ARM: EXYNOS: Fix support of Exynos4210 rev0 SoC
On Monday 15 April 2013, Tomasz Figa wrote: > This patch extends exynos_init_time() function to handle Exynos4210 rev0 > SoC, which differs in availability of system timers and needs different > clocksource initialization. > > This makes it possible to use exynos_init_time() function as init_time > callback for all Exynos-based boards, including Universal_C210, which > originally had to use samsung_timer_init(). > > Signed-off-by: Tomasz Figa Acked-by: Arnd Bergmann Note that it would be helpful to mention here that this is required for the calling samsung_timer_init from the exynos4-dt.c file. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] ARM: dts: exynos4: Add node for PWM device
On Monday 15 April 2013, Tomasz Figa wrote:
> This patch adds device tree node for PWM block present on Exynos 4 SoCs.
>
> Signed-off-by: Tomasz Figa
> ---
> arch/arm/boot/dts/exynos4.dtsi | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index d73eaa1..d7058c1 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -333,6 +333,14 @@
> status = "disabled";
> };
>
> + pwm@139D {
> + compatible = "samsung,exynos4210-pwm";
> + reg = <0x139D 0x1000>;
> + interrupts = <0 37 0>, <0 38 0>, <0 39 0>, <0 40 0>, <0 41 0>;
> + #pwm-cells = <2>;
> + status = "disabled";
> + };
Acked-by: Arnd Bergmann
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 00/14] ARM: samsung-time: Prepare for multiplatform support
On Tuesday 23 of April 2013 02:37:33 Kukjin Kim wrote: > On 04/13/13 05:51, Arnd Bergmann wrote: > > On Friday 12 April 2013, Tomasz Figa wrote: > >> This series is an attempt to make the samsung-time clocksource driver > >> ready for multiplatform kernels. It moves the driver to > >> drivers/clocksource, cleans it up from uses of static > >> platform-specific definitions, simplifies timer interrupt handling > >> and adds Device Tree support. > >> > >> The samsung_pwm clocksource driver is made the master driver, which > >> exposes a single function to the PWM driver to get required data. > >> Only > >> samsung-time driver is reworked to use the master driver at this > >> time, > >> since the PWM driver can be already considered broken at the moment > >> and > >> needs separate series of several patches to fix and clean it up, > >> which > >> I am already working on. > >> > >> Tested on Universal C210 board with Device Tree. Not tested without > >> Device Tree, since it has been already broken before this series. > >> Compile tested for other related SoCs. > > > > Acked-by: Arnd Bergmann > > Applied, this whole series. It would be nice if we could still get this for 3.10, but AFAIK it is already much too late. I've discussed this matter with Arnd and the solution that can be accepted by arm-soc maintainers is to send a subset of this series, like in the patch sent by Arnd (clocksource: add samsung pwm timer driver; it needs additional fixes, though.). Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: EXYNOS: no more support non-DT for EXYNOS SoCs
On Monday 22 April 2013, Kukjin Kim wrote: > On 04/10/13 23:05, Kukjin Kim wrote: > > On 04/10/13 22:55, Arnd Bergmann wrote: > >> On Wednesday 10 April 2013, Sylwester Nawrocki wrote: > >>> Hmm, it turns out we are still actively using some boards based on > >>> Exynos4210 EVT0 SoCs. And since it seems unlikely the patches from > >>> Tomasz [1] adding basic DT support for those will get merged for > >>> 3.10, it would be a bit inconvenient to remove the ATAGS support > >>> now, leaving Exynos4210 Rev. 0 not supported at all. > >> > >> I still have hope to get those included. > >> > > I agree and I asked Tomasz to re-send universal dt patch. > > > Hi Arnd and Olof, > > Is it possible to send one more pull-request for this and something like > dt patches for exynos? I think it's too late for that now, let's just fix the broken pieces now and do the minimum amount of patches on top of what we have: * Thomas Abraham's fix for the clk code * Tomasz Figa's patch to restore Universal C210 * Whatever is needed to get USB working again on Arndale * Anything else that comes up that is really a bug fix. * Getting the PWM and ADC drivers working with DT, that can easily be done. * Possibly a patch to mark CONFIG_EXYNOS_ATAGS as broken, if you think that helps. but not: * The entire series to rework the PWM clock from Tomasz * The entire series to remove ATAGS support on Exynos * Any other non-bugfix patches Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] ARM: EXYNOS: DT-enabled support for Universal C210
On 04/15/13 23:41, Tomasz Figa wrote: This series intends to add support for Universal C210 board using Device Tree. Main difference from other boards based on Exynos 4210 is that hardware revision of the SoC used on Universal C210 does not support MCT timers and legacy PWM timers must be used instead. First patch adds device tree node for PWM block available on Exynos4 SoCs, second patch adds support for Exynos4210 rev0 SoC in exynos_init_time() and third patch introduces initial device tree for Universal C210 board. Depends on my series for PWM timers rework: [PATCH v5 00/14] ARM: samsung-time: Prepare for multiplatform support (http://thread.gmane.org/gmane.linux.kernel.samsung-soc/17864) On Universal C210 board: Tested-by: Tomasz Figa Tomasz Figa (3): ARM: dts: exynos4: Add node for PWM device ARM: EXYNOS: Fix support of Exynos4210 rev0 SoC ARM: dts: exynos4210: Add basic dts file for universal_c210 board arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/exynos4.dtsi | 8 + arch/arm/boot/dts/exynos4210-universal_c210.dts | 352 arch/arm/mach-exynos/common.c | 6 +- arch/arm/mach-exynos/mach-universal_c210.c | 2 +- 5 files changed, 367 insertions(+), 2 deletions(-) create mode 100644 arch/arm/boot/dts/exynos4210-universal_c210.dts Applied, thanks. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: exynos5250: Fix divider values for sclk_mmc{0,1,2,3}
Hi,
On Tue, Apr 16, 2013 at 12:35 PM, Doug Anderson wrote:
> Hi,
>
> On Mon, Apr 8, 2013 at 12:22 AM, Kukjin Kim wrote:
>> Mike Turquette wrote:
>>>
>>> Quoting Tushar Behera (2013-04-02 01:20:40)
>>> > In legacy setup, sclk_mmc{0,1,2,3} used PRE_RATIO bit-field (8-bit wide)
>>> > instead of RATIO bit-field (4-bit wide) for dividing clock rate.
>>> >
>>> > With current common clock setup, we are using RATIO bit-field which
>>> > is creating FIFO read errors while accessing eMMC. Changing over to
>>> > use PRE_RATIO bit-field fixes this issue.
>>> >
>>> > dwmmc_exynos 1220.dwmmc0: data FIFO error (status=8020)
>>> > mmcblk0: error -5 transferring data, sector 1, nr 7, cmd response 0x900,
>>> card status 0x0
>>> > end_request: I/O error, dev mmcblk0, sector 1
>>> >
>>> > Signed-off-by: Tushar Behera
>>> > CC: Thomas Abraham
>>>
>>> I guess this will be applied through the samsung tree, so:
>>>
>>> Acked-by: Mike Turquette
>>>
>> Thanks, applied.
>
> I haven't yet had time to dig / track down why, but this patch totally
> messes up access to the eMMC on the ARM Chromebook (exynos5250-snow).
> I suddenly start getting FIFO errors like you show above. When I
> revert your change then I'm all happy.
>
> Perhaps I need a device tree setting change as well? I always forget
> how the "samsung,dw-mshc-ciu-div" / "samsung,dw-mshc-sdr-timing"
> properties work...
>
> For the short term I'm going to revert locally since I've got a few
> other things to do over the next few days. If nobody else gets around
> to it then I'll try to find time to dig further.
Unless I hear differently within 24 hours, I am going to revert this
in arm-soc (since that is where it is merged right now).
It is obviously causing regressions on existing platforms. I am _NOT_
happy to see dead silence about this for 6 days. Tushar??
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 00/14] ARM: samsung-time: Prepare for multiplatform support
On 04/13/13 05:51, Arnd Bergmann wrote: On Friday 12 April 2013, Tomasz Figa wrote: This series is an attempt to make the samsung-time clocksource driver ready for multiplatform kernels. It moves the driver to drivers/clocksource, cleans it up from uses of static platform-specific definitions, simplifies timer interrupt handling and adds Device Tree support. The samsung_pwm clocksource driver is made the master driver, which exposes a single function to the PWM driver to get required data. Only samsung-time driver is reworked to use the master driver at this time, since the PWM driver can be already considered broken at the moment and needs separate series of several patches to fix and clean it up, which I am already working on. Tested on Universal C210 board with Device Tree. Not tested without Device Tree, since it has been already broken before this series. Compile tested for other related SoCs. Acked-by: Arnd Bergmann Applied, this whole series. Thanks. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: ehci-s5p: fix: Fix null pointer dereferencing
On 04/09/13 22:12, Vivek Gautam wrote: 7edb3da: (USB: EHCI: make ehci-s5p a separate driver) raised an issue with ehci-s5p's driver data. Now that 's5p_ehci_hcd' doesn't maintain pointer to 'usb_hcd' and s5p_ehci is nothing but a pointer to hcd->priv; add hcd to the driver data rather than s5p_ehci. This fixes issues with null pointer dereferencing in s5p_ehci_shutdown(), s5p_ehci_suspend(), s5p_ehci_resume(). Signed-off-by: Vivek Gautam CC: Manjunath Goudar CC: Arnd Bergmann CC: Jingoo Han Acked-by: Kukjin Kim Thanks. - Kukjin --- Based on 'usb-next' drivers/usb/host/ehci-s5p.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c index d8cb0ca..580548a 100644 --- a/drivers/usb/host/ehci-s5p.c +++ b/drivers/usb/host/ehci-s5p.c @@ -173,7 +173,7 @@ static int s5p_ehci_probe(struct platform_device *pdev) goto fail_add_hcd; } - platform_set_drvdata(pdev, s5p_ehci); + platform_set_drvdata(pdev, hcd); return 0; -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rtc: rtc-s3c: use clk_prepare_enable and clk_disable_unprepare
On 04/11/13 13:09, Jingoo Han wrote: On Wednesday, April 10, 2013 6:50 PM, Sylwester Nawrocki wrote: On 04/09/2013 04:27 PM, Vivek Gautam wrote: From: Thomas Abraham Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare calls as required by common clock framework. Signed-off-by: Thomas Abraham Signed-off-by: Vivek Gautam Acked-by: Kukjin Kim Thanks Vivek. Reviewed-by: Sylwester Nawrocki CC'ed Andrew Morton It looks good. Reviewed-by: Jingoo Han --- The v1 of this patch is pretty old, but the change needs to be merged to avoid getting those needless WARN_ON() dumps on console. Changes from v1: - Not using clk_disable_unprepare() at the end of s3c_rtc_probe(), since this will unprepare the rtc clock which is again getting used in other funtions later. - Using clk_unprepare() at the remove() instead to fix things up. drivers/rtc/rtc-s3c.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c index fb994e9..e3528c9 100644 --- a/drivers/rtc/rtc-s3c.c +++ b/drivers/rtc/rtc-s3c.c @@ -430,6 +430,7 @@ static int s3c_rtc_remove(struct platform_device *dev) s3c_rtc_setaie(&dev->dev, 0); + clk_unprepare(rtc_clk); rtc_clk = NULL; return 0; @@ -498,7 +499,7 @@ static int s3c_rtc_probe(struct platform_device *pdev) return ret; } - clk_enable(rtc_clk); + clk_prepare_enable(rtc_clk); /* check to see if everything is setup correctly */ @@ -578,7 +579,7 @@ static int s3c_rtc_probe(struct platform_device *pdev) err_nortc: s3c_rtc_enable(pdev, 0); - clk_disable(rtc_clk); + clk_disable_unprepare(rtc_clk); return ret; } -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: EXYNOS: no more support non-DT for EXYNOS SoCs
On 04/10/13 23:05, Kukjin Kim wrote: On 04/10/13 22:55, Arnd Bergmann wrote: On Wednesday 10 April 2013, Sylwester Nawrocki wrote: Hmm, it turns out we are still actively using some boards based on Exynos4210 EVT0 SoCs. And since it seems unlikely the patches from Tomasz [1] adding basic DT support for those will get merged for 3.10, it would be a bit inconvenient to remove the ATAGS support now, leaving Exynos4210 Rev. 0 not supported at all. I still have hope to get those included. I agree and I asked Tomasz to re-send universal dt patch. Hi Arnd and Olof, Is it possible to send one more pull-request for this and something like dt patches for exynos? - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clocksource: add samsung pwm timer driver
On 04/21/13 07:01, Arnd Bergmann wrote: From: Tomasz Figa This adds a new clocksource driver for the PWM timer that is present in most Samsung SoCs, based on the existing driver in arch/arm/plat-samsung/samsung-time.c and many changes implemented by Tomasz Figa. Originally, the conversion of all Samsung machines to the new driver was planned for 3.10, but that work ended up being too late and too invasive just before the merge window. Unfortunately, other changes in the Exynos platform resulted in some Exynos4 setups, particularly the Universal C210 board to be broken. In order to fix that with minimum risk, so we now leave the existing pwm clocksource driver in place for all older platforms and use the new driver only for device tree enabled boards. This way, we can get the broken machines running again using DT descriptions. All clocksource changes were implemented by Tomasz, while the DT registration was rewritten by Arnd. Signed-off-by: Arnd Bergmann Cc: Tomasz Figa Cc: Kyungmin Park Cc: Kukjin Kim Acked-by: Kukjin Kim Thanks. - Kukjin Cc: Ben Dooks Cc: John Stultz Cc: Thomas Gleixner --- This is my final attempt to fix the Exynos4 regressions we have, since Tomasz put a lot of work into getting this running, and I gave him a hard time about some of the earlier patches. Tomasz, can you have a look at this to see if it would actually help? I have removed all the non-DT registration from your code, as well as the interface to the pwm subsystem, since I assume the existing code will work for all users we care about. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] ARM: S3C24XX: dma cleanups for s3c2412 and s3c2443
On 04/22/13 03:02, Heiko Stübner wrote: The s3c2412 uses the same dma channel selection-type as the s3c2443 and later but introduced the notion of a receive channel to keep the spi channels, together that are separate in hardware. This series split the spi channels like later socs do (the s3c24xx-spi driver does not use dma at all) and removes this type of special handling. Heiko Stuebner (3): ARM: S3C24XX: split s3c2412 spi dma channels ARM: S3C24XX: dma-s3c2443 - do not write into arbitary bits ARM: S3C24XX: remove obsolete s3c2412 specific dma settings arch/arm/mach-s3c24xx/dma-s3c2412.c | 56 ++ arch/arm/mach-s3c24xx/dma-s3c2443.c |3 +- arch/arm/mach-s3c24xx/dma.c |3 - arch/arm/plat-samsung/include/plat/dma-s3c24xx.h |5 -- 4 files changed, 17 insertions(+), 50 deletions(-) Applied, thanks. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: dts: Add TMU clock entries to exynos4210.dtsi
On 04/22/13 13:32, Sachin Kamat wrote:
Adds TMU clock entries to exynos4210.dtsi file.
Signed-off-by: Sachin Kamat
---
arch/arm/boot/dts/exynos4210.dtsi |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index 50ab9d4..53654c4 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -111,6 +111,9 @@
interrupt-parent =<&combiner>;
reg =<0x100C 0x100>;
interrupts =<2 4>;
+ clocks =<&clock 383>;
+ clock-names = "tmu_apbif";
+ status = "disabled";
};
g2d@1280 {
Applied 1st and 2nd patches.
Thanks.
- Kukjin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/3] of/pci: Provide common support for PCI DT parsing
On Mon, Apr 22, 2013 at 11:41:32AM +0100, Andrew Murray wrote: > This patchset factors out duplicated code associated with parsing PCI > DT "ranges" properties across the architectures and introduces a > "ranges" parser. This parser "of_pci_range_parser" can be used directly > by ARM host bridge drivers enabling them to obtain ranges from device > trees. > > I've included the Reviewed-by, Tested-by and Acked-by's received from v5/v6/v7 > in this patchset, earlier versions of this patchset (v3) have been tested-by: > > Thierry Reding > Jingoo Han > > I've tested that this patchset builds and runs on ARM and that it builds on > PowerPC, x86_64 and MIPS. Andrew, Unfortunately, the mvebu/drivers branch containing your series had to be dropped from arm-soc for v3.10. This was not due to your series, but since arm-soc's granularity is branches, your series was caught in the drop. As the mvebu-pcie driver is now v3.11 material, I have taken the opportunity to upgrade from your v7 patchset to v8. You can find the whole branch at mvebu-next/pcie. mvebu-next/pcie *will* be rebased onto v3.9 once it drops. Several dependencies will be removed (since they will have been merged into v3.9). Once the rebase is done, I'll send a pull request to Arnd and Olof so we can get as many cycles on -next as possible. thx, Jason. > > Compared to the v7 sent by Andrew Murray, the following changes have been made > (please note that the first patch is unchanged from v7): > > * Rename of_pci_range_parser to of_pci_range_parser_init and >of_pci_process_ranges to of_pci_range_parser_one as suggested by Grant >Likely. > > * Reverted back to using a switch statement instead of if/else in >pci_process_bridge_OF_ranges. Grant Likely highlighted this change from >the original code which was unnecessary. > > * Squashed in a patch provided by Gabor Juhos which fixes build errors on >MIPS found in the last patchset. > > Compared to the v6 sent by Andrew Murray, the following changes have > been made in response to build errors/warnings: > > * Inclusion of linux/of_address.h in of_pci.c as suggested by Michal >Simek to prevent compilation failures on Microblaze (and others) and his >ack. > > * Use of externs, static inlines and a typo in linux/of_address.h in response >to linker errors (multiple defination) on x86_64 as spotted by a kbuild > test >robot on (jcooper/linux.git mvebu/drivers) > > * Add EXPORT_SYMBOL_GPL to of_pci_range_parser function to be consistent >with of_pci_process_ranges function > > Compared to the v5 sent by Andrew Murray, the following changes have > been made: > > * Use of CONFIG_64BIT instead of CONFIG_[a32bitarch] as suggested by >Rob Herring in drivers/of/of_pci.c > > * Added forward declaration of struct pci_controller in linux/of_pci.h >to prevent compiler warning as suggested by Thomas Petazzoni > > * Improved error checking (!range check), removal of unnecessary be32_to_cpup >call, improved formatting of struct of_pci_range_parser layout and >replacement of macro with a static inline. All suggested by Rob Herring. > > Compared to the v4 (incorrectly labelled v3) sent by Andrew Murray, > the following changes have been made: > > * Split the patch as suggested by Rob Herring > > Compared to the v3 sent by Andrew Murray, the following changes have > been made: > > * Unify and move duplicate pci_process_bridge_OF_ranges functions to >drivers/of/of_pci.c as suggested by Rob Herring > > * Fix potential build errors with Microblaze/MIPS > > Compared to "[PATCH v5 01/17] of/pci: Provide support for parsing PCI DT > ranges property", the following changes have been made: > > * Correct use of IORESOURCE_* as suggested by Russell King > > * Improved interface and naming as suggested by Thierry Reding > > Compared to the v2 sent by Andrew Murray, Thomas Petazzoni did: > > * Add a memset() on the struct of_pci_range_iter when starting the >for loop in for_each_pci_range(). Otherwise, with an uninitialized >of_pci_range_iter, of_pci_process_ranges() may crash. > > * Add parenthesis around 'res', 'np' and 'iter' in the >for_each_of_pci_range macro definitions. Otherwise, passing >something like &foobar as 'res' didn't work. > > * Rebased on top of 3.9-rc2, which required fixing a few conflicts in >the Microblaze code. > > v2: > This follows on from suggestions made by Grant Likely > (marc.info/?l=linux-kernel&m=136079602806328) > > Andrew Murray (3): > of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and > PowerPC > of/pci: Provide support for parsing PCI DT ranges property > of/pci: mips: convert to common of_pci_range_parser > > arch/microblaze/include/asm/pci-bridge.h |5 +- > arch/microblaze/pci/pci-common.c | 192 > -- > arch/mips/pci/pci.c | 51 +++- > arch/powerpc/include/asm/pci-bridge.h
Re: [PATCH 0/6] thermal:exynos4: Thermal Measurement Unit fixes for Samsung SoCs
On 04/20/13 01:38, Lukasz Majewski wrote: This patch series provide various fixes for TMU block. Namely, support for common clock framework and proper regulator VDD_TS has been added. Moreover device tree definitions and documentation entry are now in place. Lukasz Majewski (6): clk:exynos4:TMU Thermal Measurement Unit clock added to common clock framework thermal:exynos4: TMU Common clock framework support for TMU (Thermal Monitoring Unit) thermal:exynos4: TMU device tree support for Exynos4412 targets thermal: Support for TMU regulator defined at device tree thermal:exynos4: Enable support for Exynos4412 SoCs thermal:exynos4: Add documentation for Exynos SoC thermal bindings .../devicetree/bindings/clock/exynos4-clock.txt|1 + .../devicetree/bindings/thermal/exynos-thermal.txt | 22 +++ arch/arm/boot/dts/exynos4x12.dtsi | 10 + drivers/clk/samsung/clk-exynos4.c |6 ++- drivers/thermal/exynos_thermal.c | 41 +++- 5 files changed, 70 insertions(+), 10 deletions(-) create mode 100644 Documentation/devicetree/bindings/thermal/exynos-thermal.txt Lukasz, please address comments from ml. Others looks good to me. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: Exynos: Add DT based I/O mapping for Chip-ID controller
On 04/22/13 20:20, Thomas Abraham wrote: On 4 April 2013 12:27, Kukjin Kim wrote: Thomas Abraham wrote: This patch series allows device tree enabled platforms to setup a runtime I/O mapping for the chip-id controller. This helps to remove statically defined I/O mapping for the Chip-ID controller. Thomas Abraham (2): ARM: Exynos: Create virtual I/O mapping for Chip-ID controller using device tree ARM: dts: Add chip-id controller node on Exynos4/5 SoC .../arm/samsung/samsung,exynos4210-chipid.txt | 15 ++ arch/arm/boot/dts/exynos4.dtsi |5 ++ arch/arm/boot/dts/exynos5250.dtsi |5 ++ arch/arm/mach-exynos/common.c | 53 +++- arch/arm/mach-exynos/include/mach/map.h|1 - 5 files changed, 55 insertions(+), 24 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/samsung/samsung,exynos4210- chipid.txt -- 1.7.5.4 Thomas, Can you update this series can support exynos5440 as well? It should be done together. Hi Mr. Kim, Sorry for the delayed reply. This patch series is supported for Exynos5440 as well. The v2 version of this patch series has been submitted. OK, thanks. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] ARM: Exynos: Add DT based I/O mapping for Chip-ID controller
On 04/22/13 20:35, Thomas Abraham wrote: Changes since v1: - Rebased to v3.9-rc8 This patch series allows device tree enabled platforms to setup a runtime I/O mapping for the chip-id controller. This helps to remove statically defined I/O mapping for the Chip-ID controller. This series is based on linux-next master branch and tested for Exynos4210, Exynos5250 and Exynos5440. Thomas Abraham (2): ARM: Exynos: Create virtual I/O mapping for Chip-ID controller using device tree ARM: dts: Add chip-id controller node on Exynos4/5 SoC Looks good to me, applied. Thanks. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/10] ARM: exynos multiplatform series, part 1
On 04/12/13 06:37, Arnd Bergmann wrote:
Hi Kukjin,
Hi Arnd,
These are the patches that I would like to apply directly to
the arm-soc next/multiplatform branch, unless you have any
Yeah, looks good to me.
objections. This would get all the simple stuff out of the
way, and I don't think there is a big risk of introducing
regressions with these.
OK, please go ahead and if you want to add my ack:
Acked-by: Kukjin Kim
Thanks.
- Kukjin
A lot of the other patches have already been merged into
subsystem trees. After this series in in arm-soc, what is
left comes down to
* The ASoC conversion to dmaengine won't make it unless someone
who knows that code better steps up to do it right away. This
means that we won't have audio in a 3.10 multiplatform kernel
on Exynos, but it will still work for users that don't enable
multiplatform.
* The irqchip (combiner), clk and clksource patches are all based
on top of other changesets we pulled in from your trees, so I
would not make them part of the next/multiplatform branch. We can
apply them on top of the next/drivers branch once they are
tested successfully.
* A trivial patch is needed in the end to actually make
CONFIG_ARCH_EXYNOS visible in multiplatform configurations.
We will do that as a separate patch once everything else is
there.
Please provide an ACK so I can put this into arm-soc, or let
me know if I screwed up somewhere.
Arnd
Arnd Bergmann (10):
ARM: exynos: introduce EXYNOS_ATAGS symbol
ARM: exynos: prepare for sparse IRQ
ARM: exynos: move debug-macro.S to include/debug/
ARM: samsung: move mfc device definition to s5p-dev-mfc.c
i2c: s3c2410: make header file local
mmc: sdhci-s3c: remove platform dependencies
thermal/exynos: remove unnecessary header inclusions
mtd: onenand/samsung: make regs-onenand.h file local
rtc: s3c: make header file local
ARM: exynos: enable multiplatform support
arch/arm/Kconfig | 9 +---
arch/arm/Kconfig.debug | 8
arch/arm/configs/exynos4_defconfig | 2 +-
.../mach/debug-macro.S => include/debug/exynos.S} | 12 ++---
.../plat/debug-macro.S => include/debug/samsung.S} | 2 +-
arch/arm/mach-exynos/Kconfig | 41 ++--
arch/arm/mach-exynos/Makefile | 5 +-
arch/arm/mach-exynos/common.c | 6 +++
arch/arm/mach-exynos/dev-uart.c| 1 +
arch/arm/mach-exynos/include/mach/irqs.h | 5 +-
arch/arm/mach-exynos/mach-armlex4210.c | 2 +
arch/arm/mach-exynos/mach-exynos4-dt.c | 2 +
arch/arm/mach-exynos/mach-exynos5-dt.c | 2 +
arch/arm/mach-exynos/mach-nuri.c | 2 +
arch/arm/mach-exynos/mach-origen.c | 2 +
arch/arm/mach-exynos/mach-smdk4x12.c | 2 +
arch/arm/mach-exynos/mach-smdkv310.c | 3 ++
arch/arm/mach-exynos/setup-sdhci-gpio.c| 2 +-
arch/arm/mach-s3c24xx/include/mach/debug-macro.S | 2 +-
arch/arm/mach-s3c24xx/mach-rx1950.c| 1 -
arch/arm/mach-s3c64xx/include/mach/debug-macro.S | 2 +-
arch/arm/mach-s5p64x0/include/mach/debug-macro.S | 2 +-
arch/arm/mach-s5pc100/include/mach/debug-macro.S | 2 +-
arch/arm/mach-s5pc100/setup-sdhci-gpio.c | 1 -
arch/arm/mach-s5pv210/include/mach/debug-macro.S | 2 +-
arch/arm/mach-s5pv210/setup-sdhci-gpio.c | 1 -
arch/arm/plat-samsung/Kconfig | 7 ++-
arch/arm/plat-samsung/Makefile | 8 +++-
arch/arm/plat-samsung/devs.c | 46 --
arch/arm/plat-samsung/include/plat/pm.h| 5 ++
arch/arm/plat-samsung/include/plat/sdhci.h | 56 +-
arch/arm/plat-samsung/irq-vic-timer.c | 1 +
arch/arm/plat-samsung/pm.c | 1 +
arch/arm/plat-samsung/s5p-dev-mfc.c| 42 +++-
arch/arm/plat-samsung/s5p-irq.c| 1 +
drivers/gpio/Makefile | 2 +-
drivers/i2c/busses/i2c-s3c2410.c | 3 +-
.../regs-iic.h => drivers/i2c/busses/i2c-s3c2410.h | 0
drivers/mmc/host/Kconfig | 2 +-
.../mmc/host/sdhci-s3c-regs.h | 0
drivers/mmc/host/sdhci-s3c.c | 5 +-
drivers/mtd/onenand/samsung.c | 4 +-
.../mtd/onenand/samsung.h | 2 -
drivers/rtc/rtc-s3c.c | 3 +-
.../plat/regs-rtc.h => drivers/rtc/rtc-s3c.h | 3 +-
drivers/thermal/exynos_thermal.c | 2 -
include/linux/platform_data/mmc-sdhci-s3c.h| 56 ++
47 files changed, 217 insertions(+), 153 deletions(-)
rename arch/arm/{mach-exynos/include/
Re: [PATCH 3/3] drm/exynos: Add device tree support for fimc ipp driver
On 04/19/2013 01:38 PM, Eunchul Kim wrote:
>> static void fimc_set_type_ctrl(struct fimc_context *ctx, enum fimc_wb wb)
>> @@ -1628,7 +1617,9 @@ static int fimc_ippdrv_start(struct device *dev, enum
>> drm_exynos_ipp_cmd cmd)
>> fimc_handle_lastend(ctx, true);
>>
>> /* setup FIMD */
>> -fimc_set_camblk_fimd0_wb(ctx);
>> +ret = fimc_set_camblk_fimd0_wb(ctx);
>> +if (ret < 0)
>
> - please adds error log information for indicating error.
OK, I'll add it.
>> +return ret;
>>
>> set_wb.enable = 1;
>> set_wb.refresh = property->refresh_rate;
>> @@ -1784,26 +1775,50 @@ e_clk_free:
>> return ret;
>> }
>>
>> +static int fimc_parse_dt(struct fimc_context *ctx)
>> +{
>> +struct device_node *node = ctx->dev->of_node;
>> +
>> +if (!of_property_read_bool(node, "samsung,lcd-wb"))
>
> - It also need error log ?
No, but it definitely deserves some comment why it is done like this.
Please see my other reply to Inki.
>> +return -ENODEV;
>> +
>> +if (of_property_read_u32(node, "clock-frequency",
>> +&ctx->clk_frequency))
>> +ctx->clk_frequency = FIMC_DEFAULT_LCLK_FREQUENCY;
>
> - We have many kind of H/W version of FIMC device. I think we need to use
> pdata
> instead of static value.
This is just a fallback value that will be used when "clock-frequency"
property is not found in fimc node in the device tree.
>> +ctx->id = of_alias_get_id(node, "fimc");
>> +if (ctx->id < 0)
>> +return -EINVAL;
>> +
>> +return 0;
>> +}
>> +
>> static int fimc_probe(struct platform_device *pdev)
>> {
>> struct device *dev = &pdev->dev;
>> struct fimc_context *ctx;
>> struct resource *res;
>> struct exynos_drm_ippdrv *ippdrv;
>> -struct exynos_drm_fimc_pdata *pdata;
>> -struct fimc_driverdata *ddata;
>> int ret;
>>
>> -pdata = pdev->dev.platform_data;
>> -if (!pdata) {
>> -dev_err(dev, "no platform data specified.\n");
>> -return -EINVAL;
>> -}
>> +if (!dev->of_node)
>
> - ditto.(error log)
Probably won't hurt, I'll add it.
>> +return -ENODEV;
>>
>> ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
>> if (!ctx)
>> return -ENOMEM;
>>
>> +ctx->dev = dev;
>> +
>> +ret = fimc_parse_dt(ctx);
>> +if (ret < 0)
>> +return ret;
>> +
>> +ctx->sysreg = syscon_regmap_lookup_by_phandle(dev->of_node,
>> +"samsung,sysreg");
>> +if (IS_ERR(ctx->sysreg))
>
> - ditto.(error log)
OK. Will add here as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] drm/exynos: Add device tree support for fimc ipp driver
On 04/20/2013 06:21 PM, Inki Dae wrote:
> +static int fimc_parse_dt(struct fimc_context *ctx)
> +{
> + struct device_node *node = ctx->dev->of_node;
> +
> + if (!of_property_read_bool(node, "samsung,lcd-wb"))
> + return -ENODEV;
>
>
>
> Isn't the above property really needed? This makes the use of write-back
> feature to be forced. I think some machines might not need this feature so
> their dts files have no that property.
> So in this case, drm fimc driver probing will be failed. is that correct
> action and your intention?
Sorry, I should have added a comment explaining why it is done like this.
"samsung,lcd-wb" is the hardware property, it should be in DT node of each
FIMC that has data path from LCD to its Writeback input. See [1] for full
binding description.
So for Exynos4, FIMC2, FIMC3 will be now bound to the DRM driver. And FIMC0,
FIMC1 will be bound to the V4L2 camera driver. There is complementary check
there:
if (of_property_read_bool(node, "samsung,lcd-wb"))
return -ENODEV;
Ideally there should be just one core driver for FIMC IP block, which is
associated with the fimc DT nodes. And switching between DRM and V4L2
should be possible at run-time. I think Media Controller API could be
helpful in that (note it is not V4L2 specific at all).
But this is all not trivial, especially WRT power management.
Before we have that I assume we could stick with using the "samsung,lcd-wb"
property.
> + if (of_property_read_u32(node, "clock-frequency",
> + &ctx->clk_frequency))
> + ctx->clk_frequency = FIMC_DEFAULT_LCLK_FREQUENCY;
> +
> + ctx->id = of_alias_get_id(node, "fimc");
> + if (ctx->id < 0)
> + return -EINVAL;
> +
> + return 0;
> +}
P.S. Html is frowned upon on the mailing lists, can please fix you mailer
to use plain text ?
[1]
http://git.linuxtv.org/media_tree.git/blob/master:/Documentation/devicetree/bindings/media/samsung-fimc.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] drm/exynos: Add device tree support for IPP driver
Hi Inki,
On 04/20/2013 06:11 PM, Inki Dae wrote:
> Hi Sylwester,
>
> DRM FIMC driver could be more cleaned up with this patch series. And your
> third
> patch
> And just minor issue. The second patch has build warnings like below,
>
> WARNING: static const char * array should probably be static const char *
> const
> #111: FILE: drivers/gpu/drm/exynos/exynos_drm_fimc.c:89:
> +static const char * fimc_clock_names[] = {
>
> ERROR: "foo * bar" should be "foo *bar"
> #111: FILE: drivers/gpu/drm/exynos/exynos_drm_fimc.c:89:
Oops, sorry. I'll fix those for v3.
> This is a minor issue so I can fix them. And as you already know, now drm fimc
> driver should be more cleaned up. Your patch set looks good to me but I'd like
> to take more opinions from others.
Thanks,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] drm/exynos: Rework fimc clocks handling
Hi,
On 04/19/2013 01:26 PM, Eunchul Kim wrote:
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
>> index d812c57..bc8411a 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
>> @@ -76,6 +76,27 @@ enum fimc_wb {
>> FIMC_WB_B,
>> };
>>
>> +enum {
>> +FIMC_CLK_LCLK,
>> +FIMC_CLK_GATE,
>> +FIMC_CLK_WB_A,
>> +FIMC_CLK_WB_B,
>> +FIMC_CLK_MUX,
>> +FIMC_CLK_PARENT,
>
> - What is MUX, PARENT ?
>
>> +FIMC_CLKS_MAX
>> +};
>> +
>> +static const char * fimc_clock_names[] = {
>> +[FIMC_CLK_LCLK] = "sclk_fimc",
>> +[FIMC_CLK_GATE] = "fimc",
>> +[FIMC_CLK_WB_A] = "pxl_async0",
>> +[FIMC_CLK_WB_B] = "pxl_async1",
>> +[FIMC_CLK_MUX]= "mux",
>> +[FIMC_CLK_PARENT] = "parent",
>
>
> - How can I get "mux", "parent" clock information ?
> Normally we are using "mout_mpll" in exynos4210, "mout_mpll_user" in exynos
> 4412. I want to get this two kind of clock name information.
The issue is that this driver is driver is setting parent clock, which
really belongs to other layers, like platform code or the clocks driver.
It I think it was a bad idea in the first place to code platform clock
names in this driver. The driver should use generic clock (consumer)
names for all platforms, and association with platform clocks is created
by platform code (CLKDEV_INIT()) or the device tree binding.
So for example in your dts file you might have:
fimc_2: fimc@1182 {
compatible = "samsung,exynos4212-fimc";
clocks = <&clock 258>, <&clock 130>, <&clock 386>, <&clock 17>;
clock-names = "fimc", "sclk_fimc", "mux", "parent";
};
And the clock indexes are described in Documentation/devicetree/bindings/
clock/exynos4-clock.txt. As a side note, the plain numbers should be soon
replaced with symbolic identifiers, once there is pre-processor support
in dtc.
The additional "mux" clocks comes from the fact that struct clk_clksrc
is now represented by 2 generic clocks: a gate and a mux clock.
Probably "sclk_mux" would be more clear.
>> +#define FIMC_DEFAULT_LCLK_FREQUENCY 13300UL
>
>
> - When do I use this value in the patch ?
> If not use. please remove this macro. If you want to use this value.
> please use platform data instead of macro.
Sorry, no good news. Since Exynos platform becomes dt-only the platform_data
is no more supposed to be used. We parse clock frequency from the device tree,
and FIMC_DEFAULT_LCLK_FREQUENCY is just a fallback value, that the driver will
use if there is no "clock-frequency" specified in device tree.
>> /*
>>* A structure of scaler.
>>*
>> @@ -132,15 +153,12 @@ struct fimc_driverdata {
>>*
>>* @ippdrv: prepare initialization using ippdrv.
>>* @regs_res: register resources.
>> + * @dev: pointer to the fimc device structure.
>
>
> - We already set the dev information in ippdrv structure.
> I think this value is duplicated value.
OK, I've overlooked it. Will remove that.
>>* @regs: memory mapped io registers.
>>* @lock: locking of operations.
>> - * @sclk_fimc_clk: fimc source clock.
>> - * @fimc_clk: fimc clock.
>> - * @wb_clk: writeback a clock.
>> - * @wb_b_clk: writeback b clock.
>> + * @clocks: fimc clocks.
>> + * @clk_frequency: LCLK clock frequency.
>>* @sc: scaler infomations.
>> - * @odr: ordering of YUV.
>> - * @ver: fimc version.
>>* @pol: porarity of writeback.
>>* @id: fimc id.
>>* @irq: irq number.
>> @@ -148,13 +166,12 @@ struct fimc_driverdata {
>>*/
>> struct fimc_context {
>> struct exynos_drm_ippdrvippdrv;
>> +struct device*dev;
>
> - please check this value about really need ?
Ok, I'll remove it.
>> struct resource*regs_res;
>> void __iomem*regs;
>> struct mutexlock;
>> -struct clk*sclk_fimc_clk;
>> -struct clk*fimc_clk;
>> -struct clk*wb_clk;
>> -struct clk*wb_b_clk;
>> +struct clk*clocks[FIMC_CLKS_MAX];
>> +u32clk_frequency;
>> struct fimc_scalersc;
>> struct fimc_driverdata*ddata;
>> struct exynos_drm_ipp_polpol;
>> @@ -1301,14 +1318,12 @@ static int fimc_clk_ctrl(struct fimc_context *ctx,
>> bool enable)
>> DRM_DEBUG_KMS("%s:enable[%d]\n", __func__, enable);
>>
>> if (enable) {
>> -clk_enable(ctx->sclk_fimc_clk);
>> -clk_enable(ctx->fimc_clk);
>> -clk_enable(ctx->wb_clk);
>> +clk_prepare_enable(ctx->clocks[FIMC_CLK_GATE]);
>> +clk_prepare_enable(ctx->clocks[FIMC_CLK_WB_A]);
>> ctx->suspended = false;
>> } else {
>> -clk_disable(ctx->sclk_fimc_clk);
>> -clk_disable(ctx->fimc_clk);
>> -clk_disable(ctx->wb_clk);
>> +clk_disable_unprepare(ctx->clocks[FIMC_CLK_GATE]);
>> +clk_disable_unprepare(ctx->clocks[FIMC_CLK_WB_A]);
>> ctx->suspended = true;
>> }
>>
>> @@ -1713,11
Re: [PATCH v3 00/10] ARM: exynos multiplatform series, part 1
On 22 April 2013 18:42, Arnd Bergmann wrote: > On Monday 22 April 2013, Sachin Kamat wrote: >> >> With this branch now available (merged) in linux-next (20130422), >> looks like exynos4 DT support is broken on it. Tested on Origen 4210 >> and 4412 and I get the following warnings on 4412 Origen board with >> exynos_defconfig (Note that clocks are all 0). However, it boots fine >> on Arndale board. > > I think this issue should be fixed with the patch that Thomas Abraham > just sent. Thomas, can you confirm? Yes, this issue is resolved with chip-id dt support patches, without which the parent of fin_pll clock is set as xxti (which is set to 0Hz for Origen4210) instead of xusbxti. Thomas. > >> SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 >> Preemptible hierarchical RCU implementation. >> NR_IRQS:549 >> Exynos4x12 clocks: sclk_apll = 0, sclk_mpll = 0 >> sclk_epll = 0, sclk_vpll = 0, arm_clk = 0 >> Division by zero in kernel. >> CPU: 0 PID: 0 Comm: swapper/0 Not tainted >> 3.9.0-rc8-next-20130422-00038-g20ff84f #50 >> [] (unwind_backtrace+0x0/0xf8) from [] >> (show_stack+0x10/0x14) >> [] (show_stack+0x10/0x14) from [] (Ldiv0_64+0x8/0x18) >> [] (Ldiv0_64+0x8/0x18) from [] >> (__clocksource_updatefreq_scale+0x44/0x19c) >> [] (__clocksource_updatefreq_scale+0x44/0x19c) from >> [] (__clocksource_register_scale+0xc/0x44) >> [] (__clocksource_register_scale+0xc/0x44) from [] >> (exynos4_clocksource_init+0x20/0x40) >> [] (exynos4_clocksource_init+0x20/0x40) from [] >> (mct_init_dt+0x68/0x74) >> [] (mct_init_dt+0x68/0x74) from [] >> (clocksource_of_init+0x30/0x58) >> [] (clocksource_of_init+0x30/0x58) from [] >> (time_init+0x1c/0x30) >> [] (time_init+0x1c/0x30) from [] >> (start_kernel+0x1a0/0x37c) >> [] (start_kernel+0x1a0/0x37c) from [<40008074>] (0x40008074) >> Division by zero in kernel. > > Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/10] ARM: exynos multiplatform series, part 1
On Monday 22 April 2013, Sachin Kamat wrote: > > With this branch now available (merged) in linux-next (20130422), > looks like exynos4 DT support is broken on it. Tested on Origen 4210 > and 4412 and I get the following warnings on 4412 Origen board with > exynos_defconfig (Note that clocks are all 0). However, it boots fine > on Arndale board. I think this issue should be fixed with the patch that Thomas Abraham just sent. Thomas, can you confirm? > SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 > Preemptible hierarchical RCU implementation. > NR_IRQS:549 > Exynos4x12 clocks: sclk_apll = 0, sclk_mpll = 0 > sclk_epll = 0, sclk_vpll = 0, arm_clk = 0 > Division by zero in kernel. > CPU: 0 PID: 0 Comm: swapper/0 Not tainted > 3.9.0-rc8-next-20130422-00038-g20ff84f #50 > [] (unwind_backtrace+0x0/0xf8) from [] > (show_stack+0x10/0x14) > [] (show_stack+0x10/0x14) from [] (Ldiv0_64+0x8/0x18) > [] (Ldiv0_64+0x8/0x18) from [] > (__clocksource_updatefreq_scale+0x44/0x19c) > [] (__clocksource_updatefreq_scale+0x44/0x19c) from > [] (__clocksource_register_scale+0xc/0x44) > [] (__clocksource_register_scale+0xc/0x44) from [] > (exynos4_clocksource_init+0x20/0x40) > [] (exynos4_clocksource_init+0x20/0x40) from [] > (mct_init_dt+0x68/0x74) > [] (mct_init_dt+0x68/0x74) from [] > (clocksource_of_init+0x30/0x58) > [] (clocksource_of_init+0x30/0x58) from [] > (time_init+0x1c/0x30) > [] (time_init+0x1c/0x30) from [] > (start_kernel+0x1a0/0x37c) > [] (start_kernel+0x1a0/0x37c) from [<40008074>] (0x40008074) > Division by zero in kernel. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] drm/exynos: prepare FIMD clocks
On Monday 22 of April 2013 12:05:49 Sylwester Nawrocki wrote:
> On 04/22/2013 11:56 AM, Tomasz Figa wrote:
> > On Monday 22 of April 2013 10:44:00 Viresh Kumar wrote:
> >> On 21 April 2013 20:13, Tomasz Figa wrote:
> >>> 3) after those two changes, all that remains is to fix compliance with
> >>> Common Clock Framework, in other words:
> >>>
> >>> s/clk_enable/clk_prepare_enable/
> >>>
> >>> and
> >>>
> >>> s/clk_disable/clk_disable_unprepare/
> >>
> >> We don't have to call clk_{un}prepare() everytime for your platform as
> >> you aren't doing anything in it. So just call them once at probe/remove
> >> and
> >> call clk_enable/disable everywhere else.
>
> Yes, I agree with that. Additionally clk_(un)prepare must not be called in
> atomic context, so some drivers will have to work like this anyway.
> Or the clocks could be prepared/unprepared in the device open/close file op
> for instance.
Well, I don't think drivers should make any assumptions how particular clk ops
are implemented on particular platform.
Instead, generic semantics of Common Clock Framework should be obeyed, which
AFAIK are:
1) Each clock must be prepared before enabling.
2) clk_prepare() can not be called from atomic contexts.
3) clk_prepare_enable() can be used instead of clk_prepare() + clk_enable()
when the driver does not need to enable the clock from atomic context.
Since the Exynos DRM FIMD driver does not need to do call any clock operations
in atomic contexts, the approach keeping the clock handling as simple as
possible would be to just replace all clk_{enable,disable} with
clk_{prepare_enable,disable_unprepare}, as I suggested.
CCing Mike, the maintainer of Common Clock Framework, since he's the right
person to pass any judgements when it is about clocks.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Kernel and System Framework
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/10] ARM: exynos multiplatform series, part 1
Hi Arnd, On 19 April 2013 19:06, Arnd Bergmann wrote: > On Thursday 11 April 2013, Arnd Bergmann wrote: >> These are the patches that I would like to apply directly to >> the arm-soc next/multiplatform branch, unless you have any >> objections. This would get all the simple stuff out of the >> way, and I don't think there is a big risk of introducing >> regressions with these. >> >> A lot of the other patches have already been merged into >> subsystem trees. After this series in in arm-soc, what is >> left comes down to >> >> * The ASoC conversion to dmaengine won't make it unless someone >> who knows that code better steps up to do it right away. This >> means that we won't have audio in a 3.10 multiplatform kernel >> on Exynos, but it will still work for users that don't enable >> multiplatform. >> >> * The irqchip (combiner), clk and clksource patches are all based >> on top of other changesets we pulled in from your trees, so I >> would not make them part of the next/multiplatform branch. We can >> apply them on top of the next/drivers branch once they are >> tested successfully. >> >> * A trivial patch is needed in the end to actually make >> CONFIG_ARCH_EXYNOS visible in multiplatform configurations. >> We will do that as a separate patch once everything else is >> there. >> >> Please provide an ACK so I can put this into arm-soc, or let >> me know if I screwed up somewhere. > > No reply? > > I'm putting them into the next/multiplatform branch now, with > the exception of the i2c patch that is already in the i2c > tree. > > I've tested this on the Arndale board and am putting it into > the next/multiplatform branch now as a stepping stone for > part two, which will be a late branch at best, if we decide > to merge it in 3.10. With this branch now available (merged) in linux-next (20130422), looks like exynos4 DT support is broken on it. Tested on Origen 4210 and 4412 and I get the following warnings on 4412 Origen board with exynos_defconfig (Note that clocks are all 0). However, it boots fine on Arndale board. SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 Preemptible hierarchical RCU implementation. NR_IRQS:549 Exynos4x12 clocks: sclk_apll = 0, sclk_mpll = 0 sclk_epll = 0, sclk_vpll = 0, arm_clk = 0 Division by zero in kernel. CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.9.0-rc8-next-20130422-00038-g20ff84f #50 [] (unwind_backtrace+0x0/0xf8) from [] (show_stack+0x10/0x14) [] (show_stack+0x10/0x14) from [] (Ldiv0_64+0x8/0x18) [] (Ldiv0_64+0x8/0x18) from [] (__clocksource_updatefreq_scale+0x44/0x19c) [] (__clocksource_updatefreq_scale+0x44/0x19c) from [] (__clocksource_register_scale+0xc/0x44) [] (__clocksource_register_scale+0xc/0x44) from [] (exynos4_clocksource_init+0x20/0x40) [] (exynos4_clocksource_init+0x20/0x40) from [] (mct_init_dt+0x68/0x74) [] (mct_init_dt+0x68/0x74) from [] (clocksource_of_init+0x30/0x58) [] (clocksource_of_init+0x30/0x58) from [] (time_init+0x1c/0x30) [] (time_init+0x1c/0x30) from [] (start_kernel+0x1a0/0x37c) [] (start_kernel+0x1a0/0x37c) from [<40008074>] (0x40008074) Division by zero in kernel. -- With warm regards, Sachin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] drm/exynos: prepare FIMD clocks
On Monday, April 22, 2013 12:37:36 PM Tomasz Figa wrote: > On Monday 22 of April 2013 12:17:39 Sylwester Nawrocki wrote: > > On 04/22/2013 12:03 PM, Inki Dae wrote: > > > > Also looks good to me. But what if power domain was disabled without > > > > pm > > > > runtime? In this case, you must enable the power domain at machine > > > > code or > > > > bootloader somewhere. This way would not only need some hard codes > > > > to turn > > > > the power domain on but also not manage power management fully. This > > > > is same as only the use of pm runtime interface(needing some hard > > > > codes without pm runtime) so I don't prefer to add > > > > clk_enable/disable to fimd probe(). I quite tend to force only the > > > > use of pm runtime as possible. So please add the hard codes to > > > > machine code or bootloader like you did for power domain if you > > > > want to use drm fimd without pm runtime. > > > > > > That's not how the runtime PM, clock subsystems work: > > > > > > 1) When CONFIG_PM_RUNTIME is disabled, all the used hardware must be > > > kept > > > powered on all the time. > > > > > > 2) Common Clock Framework will always gate all clocks that have zero > > > enable_count. Note that CCF support for Exynos is already merged for > > > 3.10 and it will be the only available clock support method for > > > Exynos. > > > > > > AFAIK, drivers must work correctly in both cases, with > > > CONFIG_PM_RUNTIME > > > enabled and disabled. > > > > > > Then is the driver worked correctly if the power domain to this device was > > > disabled at bootloader without CONFIG_PM_RUNTIME and with clk_enable()? I > > > think, in this case, the device wouldn't be worked correctly because the > > > power of the device remains off. So you must enable the power domain > > > somewhere. What is the difference between these two cases? > > > > How about making the driver dependant on PM_RUNTIME and making it always > > use pm_runtime_* API, regardless if the platform actually implements runtime > > PM or not ? Is there any issue in using the Runtime PM core always, rather > > than coding any workarounds in drivers when PM_RUNTIME is disabled ? > > I don't think this is a good idea. This would mean that any user that from > some reasons don't want to use PM_RUNTIME, would not be able to use the > driver > anymore. > > Rafael, Kevin, do you have any opinion on this? I agree. Drivers should work for CONFIG_PM_RUNTIME unset too and static inline stubs for all runtime PM helpers are available in that case. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: Exynos: Add DT based I/O mapping for Chip-ID controller
On 4 April 2013 12:27, Kukjin Kim wrote: > Thomas Abraham wrote: >> >> This patch series allows device tree enabled platforms to setup a runtime >> I/O mapping for the chip-id controller. This helps to remove statically >> defined I/O mapping for the Chip-ID controller. >> >> Thomas Abraham (2): >> ARM: Exynos: Create virtual I/O mapping for Chip-ID controller using >> device tree >> ARM: dts: Add chip-id controller node on Exynos4/5 SoC >> >> .../arm/samsung/samsung,exynos4210-chipid.txt | 15 ++ >> arch/arm/boot/dts/exynos4.dtsi |5 ++ >> arch/arm/boot/dts/exynos5250.dtsi |5 ++ >> arch/arm/mach-exynos/common.c | 53 > +++- >> arch/arm/mach-exynos/include/mach/map.h|1 - >> 5 files changed, 55 insertions(+), 24 deletions(-) >> create mode 100644 >> Documentation/devicetree/bindings/arm/samsung/samsung,exynos4210- >> chipid.txt >> >> -- >> 1.7.5.4 > > Thomas, > > Can you update this series can support exynos5440 as well? It should be done > together. Hi Mr. Kim, Sorry for the delayed reply. This patch series is supported for Exynos5440 as well. The v2 version of this patch series has been submitted. Thanks, Thomas. > > - Kukjin > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] ARM: dts: Add chip-id controller node on Exynos4/5 SoC
Add chip-id controller nodes for Exynos4 and Exynos5 SoCs.
Cc: Kukjin Kim
Signed-off-by: Thomas Abraham
---
arch/arm/boot/dts/exynos4.dtsi|5 +
arch/arm/boot/dts/exynos5250.dtsi |5 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index d73eaa1..efd441a 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -38,6 +38,11 @@
i2c7 = &i2c_7;
};
+ chipid@1000 {
+ compatible = "samsung,exynos4210-chipid";
+ reg = <0x1000 0x100>;
+ };
+
pd_mfc: mfc-power-domain@10023C40 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023C40 0x20>;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 6727eed..4bd9e9c 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -51,6 +51,11 @@
pinctrl3 = &pinctrl_3;
};
+ chipid@1000 {
+ compatible = "samsung,exynos4210-chipid";
+ reg = <0x1000 0x100>;
+ };
+
pd_gsc: gsc-power-domain@0x10044000 {
compatible = "samsung,exynos4210-pd";
reg = <0x10044000 0x20>;
--
1.6.6.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] ARM: Exynos: Create virtual I/O mapping for Chip-ID controller using device tree
On device tree enabled exynos platforms, retrieve the physical base address
of the chip-id controller from device tree and create a virtual I/O mapping
for the chip-id controller. This helps to remove the chip-id controller entry
from the statically defined I/O mapping tables.
Cc: Kukjin Kim
Signed-off-by: Thomas Abraham
---
arch/arm/mach-exynos/common.c | 53 +-
arch/arm/mach-exynos/include/mach/map.h |1 -
2 files changed, 30 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 8419190..64ef39e 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -120,17 +120,6 @@ static struct map_desc exynos_iodesc[] __initdata = {
},
};
-#ifdef CONFIG_ARCH_EXYNOS5
-static struct map_desc exynos5440_iodesc[] __initdata = {
- {
- .virtual= (unsigned long)S5P_VA_CHIPID,
- .pfn= __phys_to_pfn(EXYNOS5440_PA_CHIPID),
- .length = SZ_4K,
- .type = MT_DEVICE,
- },
-};
-#endif
-
static struct map_desc exynos4_iodesc[] __initdata = {
{
.virtual= (unsigned long)S3C_VA_SYS,
@@ -348,6 +337,31 @@ void __init exynos_init_late(void)
exynos_pm_late_initcall();
}
+#ifdef CONFIG_OF
+int __init exynos_fdt_map_chipid(unsigned long node, const char *uname,
+ int depth, void *data)
+{
+ struct map_desc iodesc;
+ __be32 *reg;
+ unsigned long len;
+
+ if (!of_flat_dt_is_compatible(node, "samsung,exynos4210-chipid") &&
+ !of_flat_dt_is_compatible(node, "samsung,exynos5440-clock"))
+ return 0;
+
+ reg = of_get_flat_dt_prop(node, "reg", &len);
+ if (reg == NULL || len != (sizeof(unsigned long) * 2))
+ return 0;
+
+ iodesc.pfn = __phys_to_pfn(be32_to_cpu(reg[0]));
+ iodesc.length = be32_to_cpu(reg[1]) - 1;
+ iodesc.virtual = (unsigned long)S5P_VA_CHIPID;
+ iodesc.type = MT_DEVICE;
+ iotable_init(&iodesc, 1);
+ return 1;
+}
+#endif
+
/*
* exynos_map_io
*
@@ -356,19 +370,12 @@ void __init exynos_init_late(void)
void __init exynos_init_io(struct map_desc *mach_desc, int size)
{
- struct map_desc *iodesc = exynos_iodesc;
- int iodesc_sz = ARRAY_SIZE(exynos_iodesc);
-#if defined(CONFIG_OF) && defined(CONFIG_ARCH_EXYNOS5)
- unsigned long root = of_get_flat_dt_root();
-
- /* initialize the io descriptors we need for initialization */
- if (of_flat_dt_is_compatible(root, "samsung,exynos5440")) {
- iodesc = exynos5440_iodesc;
- iodesc_sz = ARRAY_SIZE(exynos5440_iodesc);
- }
+#ifdef CONFIG_OF
+ if (initial_boot_params)
+ of_scan_flat_dt(exynos_fdt_map_chipid, NULL);
+ else
#endif
-
- iotable_init(iodesc, iodesc_sz);
+ iotable_init(exynos_iodesc, ARRAY_SIZE(exynos_iodesc));
if (mach_desc)
iotable_init(mach_desc, size);
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 99e0a79..92b29bb 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -56,7 +56,6 @@
#define EXYNOS4_PA_ONENAND_DMA 0x0C60
#define EXYNOS_PA_CHIPID 0x1000
-#define EXYNOS5440_PA_CHIPID 0x0016
#define EXYNOS4_PA_SYSCON 0x1001
#define EXYNOS5_PA_SYSCON 0x10050100
--
1.6.6.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] ARM: Exynos: Add DT based I/O mapping for Chip-ID controller
Changes since v1: - Rebased to v3.9-rc8 This patch series allows device tree enabled platforms to setup a runtime I/O mapping for the chip-id controller. This helps to remove statically defined I/O mapping for the Chip-ID controller. This series is based on linux-next master branch and tested for Exynos4210, Exynos5250 and Exynos5440. Thomas Abraham (2): ARM: Exynos: Create virtual I/O mapping for Chip-ID controller using device tree ARM: dts: Add chip-id controller node on Exynos4/5 SoC -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 2/3] of/pci: Provide support for parsing PCI DT ranges property
This patch factors out common implementation patterns to reduce overall kernel
code and provide a means for host bridge drivers to directly obtain struct
resources from the DT's ranges property without relying on architecture specific
DT handling. This will make it easier to write archiecture independent host
bridge
drivers and mitigate against further duplication of DT parsing code.
This patch can be used in the following way:
struct of_pci_range_parser parser;
struct of_pci_range range;
if (of_pci_range_parser_init(&parser, np))
; //no ranges property
for_each_of_pci_range(&parser, &range) {
/*
directly access properties of the address range, e.g.:
range.pci_space, range.pci_addr, range.cpu_addr,
range.size, range.flags
alternatively obtain a struct resource, e.g.:
struct resource res;
of_pci_range_to_resource(&range, np, &res);
*/
}
Additionally the implementation takes care of adjacent ranges and merges them
into a single range (as was the case with powerpc and microblaze).
Signed-off-by: Andrew Murray
Signed-off-by: Liviu Dudau
Signed-off-by: Thomas Petazzoni
Reviewed-by: Rob Herring
Tested-by: Thomas Petazzoni
Tested-by: Linus Walleij
Acked-by: Grant Likely
---
drivers/of/address.c | 67 ++
drivers/of/of_pci.c| 113 +---
include/linux/of_address.h | 48 +++
3 files changed, 158 insertions(+), 70 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 04da786..fdd0636 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -227,6 +227,73 @@ int of_pci_address_to_resource(struct device_node *dev,
int bar,
return __of_address_to_resource(dev, addrp, size, flags, NULL, r);
}
EXPORT_SYMBOL_GPL(of_pci_address_to_resource);
+
+int of_pci_range_parser_init(struct of_pci_range_parser *parser,
+ struct device_node *node)
+{
+ const int na = 3, ns = 2;
+ int rlen;
+
+ parser->node = node;
+ parser->pna = of_n_addr_cells(node);
+ parser->np = parser->pna + na + ns;
+
+ parser->range = of_get_property(node, "ranges", &rlen);
+ if (parser->range == NULL)
+ return -ENOENT;
+
+ parser->end = parser->range + rlen / sizeof(__be32);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_pci_range_parser_init);
+
+struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser
*parser,
+ struct of_pci_range *range)
+{
+ const int na = 3, ns = 2;
+
+ if (!range)
+ return NULL;
+
+ if (!parser->range || parser->range + parser->np > parser->end)
+ return NULL;
+
+ range->pci_space = parser->range[0];
+ range->flags = of_bus_pci_get_flags(parser->range);
+ range->pci_addr = of_read_number(parser->range + 1, ns);
+ range->cpu_addr = of_translate_address(parser->node,
+ parser->range + na);
+ range->size = of_read_number(parser->range + parser->pna + na, ns);
+
+ parser->range += parser->np;
+
+ /* Now consume following elements while they are contiguous */
+ while (parser->range + parser->np <= parser->end) {
+ u32 flags, pci_space;
+ u64 pci_addr, cpu_addr, size;
+
+ pci_space = be32_to_cpup(parser->range);
+ flags = of_bus_pci_get_flags(parser->range);
+ pci_addr = of_read_number(parser->range + 1, ns);
+ cpu_addr = of_translate_address(parser->node,
+ parser->range + na);
+ size = of_read_number(parser->range + parser->pna + na, ns);
+
+ if (flags != range->flags)
+ break;
+ if (pci_addr != range->pci_addr + range->size ||
+ cpu_addr != range->cpu_addr + range->size)
+ break;
+
+ range->size += size;
+ parser->range += parser->np;
+ }
+
+ return range;
+}
+EXPORT_SYMBOL_GPL(of_pci_range_parser_one);
+
#endif /* CONFIG_PCI */
/*
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 1626172..3c49ab2 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -2,6 +2,7 @@
#include
#include
#include
+#include
#include
#if defined(CONFIG_PPC32) || defined(CONFIG_PPC64) ||
defined(CONFIG_MICROBLAZE)
@@ -82,67 +83,42 @@ EXPORT_SYMBOL_GPL(of_pci_find_child_device);
void pci_process_bridge_OF_ranges(struct pci_controller *hose,
struct device_node *dev, int primary)
{
- const u32 *ranges;
- int rlen;
- int pna = of_n_addr_cells(dev);
- int np = pna + 5;
[PATCH v8 0/3] of/pci: Provide common support for PCI DT parsing
This patchset factors out duplicated code associated with parsing PCI DT "ranges" properties across the architectures and introduces a "ranges" parser. This parser "of_pci_range_parser" can be used directly by ARM host bridge drivers enabling them to obtain ranges from device trees. I've included the Reviewed-by, Tested-by and Acked-by's received from v5/v6/v7 in this patchset, earlier versions of this patchset (v3) have been tested-by: Thierry Reding Jingoo Han I've tested that this patchset builds and runs on ARM and that it builds on PowerPC, x86_64 and MIPS. Compared to the v7 sent by Andrew Murray, the following changes have been made (please note that the first patch is unchanged from v7): * Rename of_pci_range_parser to of_pci_range_parser_init and of_pci_process_ranges to of_pci_range_parser_one as suggested by Grant Likely. * Reverted back to using a switch statement instead of if/else in pci_process_bridge_OF_ranges. Grant Likely highlighted this change from the original code which was unnecessary. * Squashed in a patch provided by Gabor Juhos which fixes build errors on MIPS found in the last patchset. Compared to the v6 sent by Andrew Murray, the following changes have been made in response to build errors/warnings: * Inclusion of linux/of_address.h in of_pci.c as suggested by Michal Simek to prevent compilation failures on Microblaze (and others) and his ack. * Use of externs, static inlines and a typo in linux/of_address.h in response to linker errors (multiple defination) on x86_64 as spotted by a kbuild test robot on (jcooper/linux.git mvebu/drivers) * Add EXPORT_SYMBOL_GPL to of_pci_range_parser function to be consistent with of_pci_process_ranges function Compared to the v5 sent by Andrew Murray, the following changes have been made: * Use of CONFIG_64BIT instead of CONFIG_[a32bitarch] as suggested by Rob Herring in drivers/of/of_pci.c * Added forward declaration of struct pci_controller in linux/of_pci.h to prevent compiler warning as suggested by Thomas Petazzoni * Improved error checking (!range check), removal of unnecessary be32_to_cpup call, improved formatting of struct of_pci_range_parser layout and replacement of macro with a static inline. All suggested by Rob Herring. Compared to the v4 (incorrectly labelled v3) sent by Andrew Murray, the following changes have been made: * Split the patch as suggested by Rob Herring Compared to the v3 sent by Andrew Murray, the following changes have been made: * Unify and move duplicate pci_process_bridge_OF_ranges functions to drivers/of/of_pci.c as suggested by Rob Herring * Fix potential build errors with Microblaze/MIPS Compared to "[PATCH v5 01/17] of/pci: Provide support for parsing PCI DT ranges property", the following changes have been made: * Correct use of IORESOURCE_* as suggested by Russell King * Improved interface and naming as suggested by Thierry Reding Compared to the v2 sent by Andrew Murray, Thomas Petazzoni did: * Add a memset() on the struct of_pci_range_iter when starting the for loop in for_each_pci_range(). Otherwise, with an uninitialized of_pci_range_iter, of_pci_process_ranges() may crash. * Add parenthesis around 'res', 'np' and 'iter' in the for_each_of_pci_range macro definitions. Otherwise, passing something like &foobar as 'res' didn't work. * Rebased on top of 3.9-rc2, which required fixing a few conflicts in the Microblaze code. v2: This follows on from suggestions made by Grant Likely (marc.info/?l=linux-kernel&m=136079602806328) Andrew Murray (3): of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC of/pci: Provide support for parsing PCI DT ranges property of/pci: mips: convert to common of_pci_range_parser arch/microblaze/include/asm/pci-bridge.h |5 +- arch/microblaze/pci/pci-common.c | 192 -- arch/mips/pci/pci.c | 51 +++- arch/powerpc/include/asm/pci-bridge.h|5 +- arch/powerpc/kernel/pci-common.c | 192 -- drivers/of/address.c | 67 +++ drivers/of/of_pci.c | 173 +++ include/linux/of_address.h | 48 include/linux/of_pci.h |4 + 9 files changed, 313 insertions(+), 424 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 3/3] of/pci: mips: convert to common of_pci_range_parser
This patch converts the pci_load_of_ranges function to use the new common
of_pci_range_parser.
Signed-off-by: Andrew Murray
Signed-off-by: Liviu Dudau
Signed-off-by: Gabor Juhos
Reviewed-by: Rob Herring
Reviewed-by: Grant Likely
Tested-by: Linus Walleij
---
arch/mips/pci/pci.c | 51 +++
1 files changed, 19 insertions(+), 32 deletions(-)
diff --git a/arch/mips/pci/pci.c b/arch/mips/pci/pci.c
index 0872f12..4b09ca8 100644
--- a/arch/mips/pci/pci.c
+++ b/arch/mips/pci/pci.c
@@ -122,51 +122,38 @@ static void pcibios_scanbus(struct pci_controller *hose)
#ifdef CONFIG_OF
void pci_load_of_ranges(struct pci_controller *hose, struct device_node *node)
{
- const __be32 *ranges;
- int rlen;
- int pna = of_n_addr_cells(node);
- int np = pna + 5;
+ struct of_pci_range range;
+ struct of_pci_range_parser parser;
+ u32 res_type;
pr_info("PCI host bridge %s ranges:\n", node->full_name);
- ranges = of_get_property(node, "ranges", &rlen);
- if (ranges == NULL)
- return;
hose->of_node = node;
- while ((rlen -= np * 4) >= 0) {
- u32 pci_space;
+ if (of_pci_range_parser_init(&parser, node))
+ return;
+
+ for_each_of_pci_range(&parser, &range) {
struct resource *res = NULL;
- u64 addr, size;
-
- pci_space = be32_to_cpup(&ranges[0]);
- addr = of_translate_address(node, ranges + 3);
- size = of_read_number(ranges + pna + 3, 2);
- ranges += np;
- switch ((pci_space >> 24) & 0x3) {
- case 1: /* PCI IO space */
+
+ switch (range.flags & IORESOURCE_TYPE_BITS) {
+ case IORESOURCE_IO:
pr_info(" IO 0x%016llx..0x%016llx\n",
- addr, addr + size - 1);
+ range.cpu_addr,
+ range.cpu_addr + range.size - 1);
hose->io_map_base =
- (unsigned long)ioremap(addr, size);
+ (unsigned long)ioremap(range.cpu_addr,
+ range.size);
res = hose->io_resource;
- res->flags = IORESOURCE_IO;
break;
- case 2: /* PCI Memory space */
- case 3: /* PCI 64 bits Memory space */
+ case IORESOURCE_MEM:
pr_info(" MEM 0x%016llx..0x%016llx\n",
- addr, addr + size - 1);
+ range.cpu_addr,
+ range.cpu_addr + range.size - 1);
res = hose->mem_resource;
- res->flags = IORESOURCE_MEM;
break;
}
- if (res != NULL) {
- res->start = addr;
- res->name = node->full_name;
- res->end = res->start + size - 1;
- res->parent = NULL;
- res->sibling = NULL;
- res->child = NULL;
- }
+ if (res != NULL)
+ of_pci_range_to_resource(&range, node, res);
}
}
#endif
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
The pci_process_bridge_OF_ranges function, used to parse the "ranges"
property of a PCI host device, is found in both Microblaze and PowerPC
architectures. These implementations are nearly identical. This patch
moves this common code to a common place.
Signed-off-by: Andrew Murray
Signed-off-by: Liviu Dudau
Reviewed-by: Rob Herring
Tested-by: Thomas Petazzoni
Tested-by: Linus Walleij
Acked-by: Michal Simek
Acked-by: Grant Likely
---
arch/microblaze/include/asm/pci-bridge.h |5 +-
arch/microblaze/pci/pci-common.c | 192
arch/powerpc/include/asm/pci-bridge.h|5 +-
arch/powerpc/kernel/pci-common.c | 192
drivers/of/of_pci.c | 200 ++
include/linux/of_pci.h |4 +
6 files changed, 206 insertions(+), 392 deletions(-)
diff --git a/arch/microblaze/include/asm/pci-bridge.h
b/arch/microblaze/include/asm/pci-bridge.h
index cb5d397..5783cd6 100644
--- a/arch/microblaze/include/asm/pci-bridge.h
+++ b/arch/microblaze/include/asm/pci-bridge.h
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
struct device_node;
@@ -132,10 +133,6 @@ extern void setup_indirect_pci(struct pci_controller *hose,
extern struct pci_controller *pci_find_hose_for_OF_device(
struct device_node *node);
-/* Fill up host controller resources from the OF node */
-extern void pci_process_bridge_OF_ranges(struct pci_controller *hose,
- struct device_node *dev, int primary);
-
/* Allocate & free a PCI host bridge structure */
extern struct pci_controller *pcibios_alloc_controller(struct device_node
*dev);
extern void pcibios_free_controller(struct pci_controller *phb);
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 9ea521e..2735ad9 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -622,198 +622,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int
bar,
*end = rsrc->end - offset;
}
-/**
- * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
- * @hose: newly allocated pci_controller to be setup
- * @dev: device node of the host bridge
- * @primary: set if primary bus (32 bits only, soon to be deprecated)
- *
- * This function will parse the "ranges" property of a PCI host bridge device
- * node and setup the resource mapping of a pci controller based on its
- * content.
- *
- * Life would be boring if it wasn't for a few issues that we have to deal
- * with here:
- *
- * - We can only cope with one IO space range and up to 3 Memory space
- * ranges. However, some machines (thanks Apple !) tend to split their
- * space into lots of small contiguous ranges. So we have to coalesce.
- *
- * - We can only cope with all memory ranges having the same offset
- * between CPU addresses and PCI addresses. Unfortunately, some bridges
- * are setup for a large 1:1 mapping along with a small "window" which
- * maps PCI address 0 to some arbitrary high address of the CPU space in
- * order to give access to the ISA memory hole.
- * The way out of here that I've chosen for now is to always set the
- * offset based on the first resource found, then override it if we
- * have a different offset and the previous was set by an ISA hole.
- *
- * - Some busses have IO space not starting at 0, which causes trouble with
- * the way we do our IO resource renumbering. The code somewhat deals with
- * it for 64 bits but I would expect problems on 32 bits.
- *
- * - Some 32 bits platforms such as 4xx can have physical space larger than
- * 32 bits so we need to use 64 bits values for the parsing
- */
-void pci_process_bridge_OF_ranges(struct pci_controller *hose,
- struct device_node *dev, int primary)
-{
- const u32 *ranges;
- int rlen;
- int pna = of_n_addr_cells(dev);
- int np = pna + 5;
- int memno = 0, isa_hole = -1;
- u32 pci_space;
- unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
- unsigned long long isa_mb = 0;
- struct resource *res;
-
- pr_info("PCI host bridge %s %s ranges:\n",
- dev->full_name, primary ? "(primary)" : "");
-
- /* Get ranges property */
- ranges = of_get_property(dev, "ranges", &rlen);
- if (ranges == NULL)
- return;
-
- /* Parse it */
- pr_debug("Parsing ranges property...\n");
- while ((rlen -= np * 4) >= 0) {
- /* Read next ranges element */
- pci_space = ranges[0];
- pci_addr = of_read_number(ranges + 1, 2);
- cpu_addr = of_translate_address(dev, ranges + 3);
- size = of_read_number(ranges + pna + 3, 2);
-
- pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
-
Re: [PATCH v4] drm/exynos: prepare FIMD clocks
On Monday 22 of April 2013 12:17:39 Sylwester Nawrocki wrote: > On 04/22/2013 12:03 PM, Inki Dae wrote: > > > Also looks good to me. But what if power domain was disabled without > > > pm > > > runtime? In this case, you must enable the power domain at machine > > > code or > > > bootloader somewhere. This way would not only need some hard codes > > > to turn > > > the power domain on but also not manage power management fully. This > > > is same as only the use of pm runtime interface(needing some hard > > > codes without pm runtime) so I don't prefer to add > > > clk_enable/disable to fimd probe(). I quite tend to force only the > > > use of pm runtime as possible. So please add the hard codes to > > > machine code or bootloader like you did for power domain if you > > > want to use drm fimd without pm runtime. > > > > That's not how the runtime PM, clock subsystems work: > > > > 1) When CONFIG_PM_RUNTIME is disabled, all the used hardware must be > > kept > > powered on all the time. > > > > 2) Common Clock Framework will always gate all clocks that have zero > > enable_count. Note that CCF support for Exynos is already merged for > > 3.10 and it will be the only available clock support method for > > Exynos. > > > > AFAIK, drivers must work correctly in both cases, with > > CONFIG_PM_RUNTIME > > enabled and disabled. > > > > Then is the driver worked correctly if the power domain to this device was > > disabled at bootloader without CONFIG_PM_RUNTIME and with clk_enable()? I > > think, in this case, the device wouldn't be worked correctly because the > > power of the device remains off. So you must enable the power domain > > somewhere. What is the difference between these two cases? > > How about making the driver dependant on PM_RUNTIME and making it always > use pm_runtime_* API, regardless if the platform actually implements runtime > PM or not ? Is there any issue in using the Runtime PM core always, rather > than coding any workarounds in drivers when PM_RUNTIME is disabled ? I don't think this is a good idea. This would mean that any user that from some reasons don't want to use PM_RUNTIME, would not be able to use the driver anymore. Rafael, Kevin, do you have any opinion on this? Best regards, -- Tomasz Figa Samsung Poland R&D Center SW Solution Development, Kernel and System Framework -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] drm/exynos: prepare FIMD clocks
On 22 April 2013 15:26, Tomasz Figa wrote: > Can you assure that in future SoCs, on which this driver will be used, this > assumption will still hold true or even that in current Exynos driver this > behavior won't be changed? Probably yes.. Registers for enabling/disabling these clocks should always be on AMBA bus and not on SPI/I2C, i.e. on-soc... and so this will hold true. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] drm/exynos: prepare FIMD clocks
On 04/22/2013 12:03 PM, Inki Dae wrote: > > Also looks good to me. But what if power domain was disabled without pm > > runtime? In this case, you must enable the power domain at machine code > or > > bootloader somewhere. This way would not only need some hard codes to > turn > > the power domain on but also not manage power management fully. This is > same > > as only the use of pm runtime interface(needing some hard codes without > pm > > runtime) so I don't prefer to add clk_enable/disable to fimd probe(). I > quite > > tend to force only the use of pm runtime as possible. So please add the > hard > > codes to machine code or bootloader like you did for power domain if you > > want to use drm fimd without pm runtime. > > That's not how the runtime PM, clock subsystems work: > > 1) When CONFIG_PM_RUNTIME is disabled, all the used hardware must be kept > powered on all the time. > > 2) Common Clock Framework will always gate all clocks that have zero > enable_count. Note that CCF support for Exynos is already merged for 3.10 > and > it will be the only available clock support method for Exynos. > > AFAIK, drivers must work correctly in both cases, with CONFIG_PM_RUNTIME > enabled and disabled. > > > Then is the driver worked correctly if the power domain to this device was > disabled at bootloader without CONFIG_PM_RUNTIME and with clk_enable()? I > think, in this case, the device wouldn't be worked correctly because the power > of the device remains off. So you must enable the power domain somewhere. What > is the difference between these two cases? How about making the driver dependant on PM_RUNTIME and making it always use pm_runtime_* API, regardless if the platform actually implements runtime PM or not ? Is there any issue in using the Runtime PM core always, rather than coding any workarounds in drivers when PM_RUNTIME is disabled ? Thanks, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] drm/exynos: prepare FIMD clocks
On 04/22/2013 11:56 AM, Tomasz Figa wrote:
> On Monday 22 of April 2013 10:44:00 Viresh Kumar wrote:
>> On 21 April 2013 20:13, Tomasz Figa wrote:
>>> 3) after those two changes, all that remains is to fix compliance with
>>> Common Clock Framework, in other words:
>>>
>>> s/clk_enable/clk_prepare_enable/
>>>
>>> and
>>>
>>> s/clk_disable/clk_disable_unprepare/
>>
>> We don't have to call clk_{un}prepare() everytime for your platform as
>> you aren't doing anything in it. So just call them once at probe/remove and
>> call clk_enable/disable everywhere else.
Yes, I agree with that. Additionally clk_(un)prepare must not be called in
atomic context, so some drivers will have to work like this anyway.
Or the clocks could be prepared/unprepared in the device open/close file op
for instance.
> Can you assure that in future SoCs, on which this driver will be used, this
> assumption will still hold true or even that in current Exynos driver this
> behavior won't be changed?
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] drm/exynos: prepare FIMD clocks
On Monday 22 of April 2013 10:44:00 Viresh Kumar wrote:
> On 21 April 2013 20:13, Tomasz Figa wrote:
> > 3) after those two changes, all that remains is to fix compliance with
> > Common Clock Framework, in other words:
> >
> > s/clk_enable/clk_prepare_enable/
> >
> > and
> >
> > s/clk_disable/clk_disable_unprepare/
>
> We don't have to call clk_{un}prepare() everytime for your platform as
> you aren't doing anything in it. So just call them once at probe/remove and
> call clk_enable/disable everywhere else.
Can you assure that in future SoCs, on which this driver will be used, this
assumption will still hold true or even that in current Exynos driver this
behavior won't be changed?
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Kernel and System Framework
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] drm/exynos: prepare FIMD clocks
On Sunday 21 of April 2013 22:36:08 Inki Dae wrote:
> > > 2013/4/21 Tomasz Figa
> > >
> > > > Hi,
> > > >
> > > > On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> > > > > On 8 April 2013 16:37, Vikas Sajjan wrote:
> > > > > > While migrating to common clock framework (CCF), I found that the
> > > > > > FIMD
> > > > > > clocks were pulled down by the CCF.
> > > > > > If CCF finds any clock(s) which has NOT been claimed by any of the
> > > > > > drivers, then such clock(s) are PULLed low by CCF.
> > > > > >
> > > > > > Calling clk_prepare() for FIMD clocks fixes the issue.
> > > > > >
> > > > > > This patch also replaces clk_disable() with clk_unprepare() during
> > > > > > exit, since clk_prepare() is called in fimd_probe().
> > > > >
> > > > > I asked you about fixing your commit log too.. It still looks
> > > > > incorrect
> > > > > to me.
> > > > >
> > > > > This patch doesn't have anything to do with CCF pulling clocks down,
> > > > > but calling clk_prepare() before clk_enable() is must now.. that's
> > > > > it.. nothing more.
> > > >
> > > > I fully agree.
> > > >
> > > > The message should be something like:
> > > >
> > > > Common Clock Framework introduced the need to prepare clocks before
> > > > enabling them, otherwise clk_enable() fails. This patch adds
> > > > clk_prepare calls to the driver.
> > > >
> > > > and that's all.
> > > >
> > > > What you are observing as "CCF pulling clocks down" is the fact that
> > > > clk_enable() fails if the clock is not prepared and so the clock is
> > > > not
> > > > enabled in result.
> > > >
> > > > Another thing is that CCF is not pulling anything down. GPIO pins can
> > > > be pulled down (or up or not pulled), but clocks can be masked, gated
> > > > or simply disabled - this does not imply their signal level.
> > > >
> > > > > > Signed-off-by: Vikas Sajjan
> > > > > > ---
> > > > > >
> > > > > > Changes since v3:
> > > > > > - added clk_prepare() in fimd_probe() and clk_unprepare()
> > > > > > in
> > > > > > fimd_remove()>
> > > > > >
> > > > > > as suggested by Viresh Kumar
> > > > > >
> > > > > > Changes since v2:
> > > > > > - moved clk_prepare_enable() and clk_disable_unprepare()
> > > > > > from
> > > > > > fimd_probe() to fimd_clock() as suggested by Inki Dae
> > > > > > >
> > > > > >
> > > > > > Changes since v1:
> > > > > > - added error checking for clk_prepare_enable() and also
> > > > > > replaced
> > > > > > clk_disable() with clk_disable_unprepare() during exit.
> > > > > >
> > > > > > ---
> > > > > >
> > > > > > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 --
> > > > > > 1 file changed, 12 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > > > > > b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 9537761..aa22370
> > > > > > 100644
> > > > > > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > > > > > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > > > > > @@ -934,6 +934,16 @@ static int fimd_probe(struct platform_device
> > > > > > *pdev)>
> > > > > >
> > > > > > return ret;
> > > > > >
> > > > > > }
> > > > > >
> > > > > > + ret = clk_prepare(ctx->bus_clk);
> > > > > > + if (ret < 0)
> > > > > > + return ret;
> > > > > > +
> > > > > > + ret = clk_prepare(ctx->lcd_clk);
> > > > > > + if (ret < 0) {
> > > > > > + clk_unprepare(ctx->bus_clk);
> > > > > > + return ret;
> > > > > > + }
> > > > > > +
> > > >
> > > > Why not just simply use clk_prepare_enable() instead of all calls to
> > > > clk_enable() in the driver?
> > > >
> > > > Same goes for s/clk_disable/clk_disable_unprepare/ .
> > >
> > > I agree with you. Using clk_prepare_enable() is more clear. Actually I
> > > had already commented on this. Please see the patch v2. But this way
> > > also looks good to me.
> >
> >
> > Well, both versions are technically correct and will have the same effect
> > for Exynos SoC clocks, since only enable/disable ops change hardware
> > state.
> >
> > However if we look at general meaning of those generic ops, the clock will
> > remain prepared for all the time the driver is loaded, even if the device
> >
> >
> >
> > Right, so I said previous one is more clear. I gonna revert current one
and then merge previous one(v3)
> >
> >
> >
> > is runtime suspended. Again on Exynos SoCs this won't have any effect, but
> > I think we should respect general Common Clock Framework semantics anyway.
> >
> >
> > > > > > ctx->vidcon0 = pdata->vidcon0;
> > > > > > ctx->vidcon1 = pdata->vidcon1;
> > > > > > ctx->default_win = pdata->default_win;
> > > > > >
> > > > > > @@ -981,8 +991,8 @@ static int fimd_remove(struct platform_device
> > > > > > *pdev)>
> > > > > >
> > > > > > if (ctx->suspended)
> > > > > >
> > > > > > goto out;
> > >
