Re: [linux-sunxi] Re: [PATCH v3 1/4] dt: bindings: add bindings for Broadcom bcm43xx sdio devices

[Hans de Goede]

Hi,

On 07/07/2014 08:23 PM, John W. Linville wrote:
> Any word from the devicetree folks?

We changed the compatible string from brcm,bcm43xx-fmac to brcm,bcm4329-fmac
at their request, that is the only feedback we've gotten from them AFAIK.

Regards,

Hans

> 
> On Sun, Jun 29, 2014 at 04:16:58PM +0200, Hans de Goede wrote:
>> From: Arend van Spriel 
>>
>> The Broadcom bcm43xx sdio devices are fullmac devices that may be
>> integrated in ARM platforms. Currently, the brcmfmac driver for
>> these devices support use of platform data. This patch specifies
>> the bindings that allow this platform data to be expressed in the
>> devicetree.
>>
>> Reviewed-by: Hante Meuleman 
>> Reviewed-by: Franky (Zhenhui) Lin 
>> Reviewed-by: Daniel (Deognyoun) Kim 
>> Reviewed-by: Pieter-Paul Giesberts 
>> Signed-off-by: Arend van Spriel 
>> [hdego...@redhat.com: drop clk / reg_on gpio handling, as there is no 
>> consensus
>>  on how to handle this yet]
>> [hdego...@redhat.com: move from bindings/staging to bindings]
>> Signed-off-by: Hans de Goede 
>> ---
>>  .../bindings/net/wireless/brcm,bcm43xx-fmac.txt| 41 
>> ++
>>  1 file changed, 41 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt 
>> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>> new file mode 100644
>> index 000..5dbf169
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>> @@ -0,0 +1,41 @@
>> +Broadcom BCM43xx Fullmac wireless SDIO devices
>> +
>> +This node provides properties for controlling the Broadcom wireless device. 
>> The
>> +node is expected to be specified as a child node to the SDIO controller that
>> +connects the device to the system.
>> +
>> +Required properties:
>> +
>> + - compatible : Should be "brcm,bcm4329-fmac".
>> +
>> +Optional properties:
>> + - brcm,drive-strength : drive strength used for SDIO pins on device in mA
>> +(default = 6).
>> + - interrupt-parent : the phandle for the interrupt controller to which the
>> +device interrupts are connected.
>> + - interrupts : specifies attributes for the out-of-band interrupt 
>> (host-wake).
>> +When not specified the device will use in-band SDIO interrupts.
>> + - interrupt-names : name of the out-of-band interrupt, which must be set
>> +to "host-wake".
>> +
>> +Example:
>> +
>> +mmc3: mmc@01c12000 {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&mmc3_pins_a>;
>> +vmmc-supply = <®_vmmc3>;
>> +bus-width = <4>;
>> +non-removable;
>> +status = "okay";
>> +
>> +brcmf: bcrmf@1 {
>> +reg = <1>;
>> +compatible = "brcm,bcm4329-fmac";
>> +interrupt-parent = <&pio>;
>> +interrupts = <10 8>; /* PH10 / EINT10 */
>> +interrupt-names = "host-wake";
>> +};
>> +};
>> -- 
>> 2.0.0
>>
>>
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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/9] PCI: Add SPEAr13xx PCie support

[Viresh Kumar]

On Tue, Jul 8, 2014 at 10:54 AM, Mohit KUMAR DCG  wrote:
> Pls find attached patches to push through your repo.  These are rebased over 
> the top
>  of 3.16-rc3.

git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git
spear/pcie-support-v8
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 7/8] ARM: Exynos: switch to using generic cpufreq-cpu0 driver

[Viresh Kumar]

Hi Arnd/Rob/Mike et al,

We didn't conclude anything out of this thread and so kicking it
again as we need to close bindings to support cpufreq-cpu0
better for platforms not sharing clock lines across all CPUs.

https://lkml.org/lkml/2014/7/1/358

On 14 May 2014 20:03, Arnd Bergmann  wrote:
> On Wednesday 14 May 2014 08:45:23 Rob Herring wrote:

>> We already have properties which indicate this driver can be used by a
>> platform: opp table and a clock for the cpu. If this information is

There can be platform drivers which also depend on these properties
and picking cpufreq-cpu0 on this basis doesn't look correct.

>> not sufficient to determine whether you can use this driver or not,
>> then you simply need to match against the platform. Perhaps the match
>> list should be a blacklist rather than a whitelist, so new platforms
>> work without a kernel change.
>
> We'd not only need a blacklist, but also a way to tell whether we
> want to use the cpu0 or the big/little implementation, which currently
> have indistinguishable bindings.

Correct and there can be other platform drivers which cannot use
cpufreq-cpu0 (though I am trying to force people to use cpufreq-cpu0
instead of a new driver).

Is something terribly wrong with having a property at 'cpus' node
which can point to the driver we want to use? Like:

cpus {
#address-cells = <1>;
#size-cells = <0>;
scaling-method = "cpufreq-cpu0"

cpu@0 {

};


};

Or if we can reuse compatibility string some way.


[Copying mail from Mike]

On 15 May 2014 02:46, Mike Turquette  wrote:
> The hardware property that matters for cpufreq-cpu0 users is that a
> multi-core CPU uses a single clock input to scale frequency across all
> of the cores in that cluster. So an accurate description is:
>
> scaling-method = "clock-ganged"; //hardware-people-speak
>
> Or,
>
> scaling-method = "clock-shared"; //software-people-speak
>
> Versus independently scalable CPUs in an SMP cluster:
>
> scaling-method = "independent"; //x86, Krait, etc.
>
> Or perhaps instead of "independent" at the parent "cpus" node we would
> put the following in each cpu@N node:
>
> scaling-method = "clock";
>
> Or "psci" or "acpi" or whatever.
>
> Thought exercise: for Hyperthreaded(tm) CPUs with 2 virtual cores for
> every hard CPU (and multiple CPUs in a cluster):
>
> scaling-method = "paired";
>
> Or more simply, "hyperthreaded".

Probably we have mixed both the problems. We have two problems to
solve:
- Identifying which driver to probe for a platform, earlier explanation
I tried to gave were around that..

- Identifying if clocks are shared between CPUs? If yes which ones?

Probably Mike's suggestions were around this second problem, but
I still couldn't make out which CPUs share clock line from his
examples.

Please see if we can close this thread soon... Few platforms are waiting
to reuse cpufreq-cpu0 :)

--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH][v2]devicetree/binding/powerpc/fsl: Add binding for CPLD

[Priyanka Jain]

Some Freescale boards like T1040RDB have on board CPLD connected on
the IFC bus. Add binding for this in board.txt file

Signed-off-by: Priyanka Jain 
---
Changes for v2: Incorporated Scott's comments

 .../devicetree/bindings/powerpc/fsl/board.txt  |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt 
b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
index 700dec4..67ef6a4 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
@@ -84,3 +84,19 @@ Example:
compatible = "fsl,bsc9132qds-fpga", "fsl,fpga-qixis-i2c";
reg = <0x66>;
};
+
+* Freescale on-board CPLD
+
+Some Freescale boards like T1040RDB have on board CPLD connected.
+
+Required properties:
+- compatible: Should be a board-specific string like "fsl,-cpld"
+  Example:
+   "fsl,T1040RDB-cpld", "fsl,T1042RDB-cpld", "fsl,T1042RDB_PI-cpld"
+- reg: should describe CPLD registers
+
+Example:
+   cpld@3,0 {
+   compatible = "fsl,T1040RDB-cpld";
+   reg = <3 0 0x300>;
+   };
-- 
1.7.4.1


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND PATCHv2 2/3] clk: exynos5420: Add IDs for clocks used in PD mfc

[Arun Kumar K]

Adds IDs for MUX clocks to be used by power domain for MFC
for doing re-parenting while pd on/off.

Signed-off-by: Arun Kumar K 
Signed-off-by: Shaik Ameer Basha 
Acked-by: Tomasz Figa 
---
 drivers/clk/samsung/clk-exynos5420.c   |6 --
 include/dt-bindings/clock/exynos5420.h |2 ++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5420.c 
b/drivers/clk/samsung/clk-exynos5420.c
index 9d7d7ee..f74f882f 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -631,7 +631,8 @@ static struct samsung_mux_clock exynos5x_mux_clks[] 
__initdata = {
SRC_TOP4, 16, 1),
MUX(0, "mout_user_aclk266", mout_user_aclk266_p, SRC_TOP4, 20, 1),
MUX(0, "mout_user_aclk166", mout_user_aclk166_p, SRC_TOP4, 24, 1),
-   MUX(0, "mout_user_aclk333", mout_user_aclk333_p, SRC_TOP4, 28, 1),
+   MUX(CLK_MOUT_USER_ACLK333, "mout_user_aclk333", mout_user_aclk333_p,
+   SRC_TOP4, 28, 1),
 
MUX(0, "mout_user_aclk400_disp1", mout_user_aclk400_disp1_p,
SRC_TOP5, 0, 1),
@@ -684,7 +685,8 @@ static struct samsung_mux_clock exynos5x_mux_clks[] 
__initdata = {
SRC_TOP11, 12, 1),
MUX(0, "mout_sw_aclk266", mout_sw_aclk266_p, SRC_TOP11, 20, 1),
MUX(0, "mout_sw_aclk166", mout_sw_aclk166_p, SRC_TOP11, 24, 1),
-   MUX(0, "mout_sw_aclk333", mout_sw_aclk333_p, SRC_TOP11, 28, 1),
+   MUX(CLK_MOUT_SW_ACLK333, "mout_sw_aclk333", mout_sw_aclk333_p,
+   SRC_TOP11, 28, 1),
 
MUX(0, "mout_sw_aclk400_disp1", mout_sw_aclk400_disp1_p,
SRC_TOP12, 4, 1),
diff --git a/include/dt-bindings/clock/exynos5420.h 
b/include/dt-bindings/clock/exynos5420.h
index 97dcb89..3fc08ff 100644
--- a/include/dt-bindings/clock/exynos5420.h
+++ b/include/dt-bindings/clock/exynos5420.h
@@ -203,6 +203,8 @@
 #define CLK_MOUT_G3D   641
 #define CLK_MOUT_VPLL  642
 #define CLK_MOUT_MAUDIO0   643
+#define CLK_MOUT_USER_ACLK333  644
+#define CLK_MOUT_SW_ACLK333645
 
 /* divider clocks */
 #define CLK_DOUT_PIXEL 768
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND PATCHv2 1/3] ARM: EXYNOS: Add support for clock handling in power domain

[Arun Kumar K]

From: Prathyush K 

While powering on/off a local powerdomain in exynos5 chipsets, the input
clocks to each device gets modified. This behaviour is based on the
SYSCLK_SYS_PWR_REG registers.
E.g. SYSCLK_MFC_SYS_PWR_REG = 0x0, the parent of input clock to MFC
   (aclk333) gets modified to oscclk
= 0x1, no change in clocks.
The recommended value of SYSCLK_SYS_PWR_REG before power gating any
domain is 0x0. So we must also restore the clocks while powering on a
domain everytime.

This patch adds the framework for getting the required mux and parent clocks
through a power domain device node. With this patch, while powering off
a domain, parent is set to oscclk and while powering back on, its re-set
to the correct parent which is as per the recommended pd on/off
sequence.

Signed-off-by: Prathyush K 
Signed-off-by: Andrew Bresticker 
Signed-off-by: Arun Kumar K 
Signed-off-by: Shaik Ameer Basha 
Reviewed-by: Tomasz Figa 
---
 .../bindings/arm/exynos/power_domain.txt   |   20 +++
 arch/arm/mach-exynos/pm_domains.c  |   61 +++-
 2 files changed, 80 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt 
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index 5216b41..8b4f7b7f 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -9,6 +9,18 @@ Required Properties:
 - reg: physical base address of the controller and length of memory mapped
 region.
 
+Optional Properties:
+- clocks: List of clock handles. The parent clocks of the input clocks to the
+   devices in this power domain are set to oscclk before power gating
+   and restored back after powering on a domain. This is required for
+   all domains which are powered on and off and not required for unused
+   domains.
+- clock-names: The following clocks can be specified:
+   - oscclk: Oscillator clock.
+   - pclkN, clkN: Pairs of parent of input clock and input clock to the
+   devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
+   are supported currently.
+
 Node of a device using power domains must have a samsung,power-domain property
 defined with a phandle to respective power domain.
 
@@ -19,6 +31,14 @@ Example:
reg = <0x10023C00 0x10>;
};
 
+   mfc_pd: power-domain@10044060 {
+   compatible = "samsung,exynos4210-pd";
+   reg = <0x10044060 0x20>;
+   clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_SW_ACLK333>,
+   <&clock CLK_MOUT_USER_ACLK333>;
+   clock-names = "oscclk", "pclk0", "clk0";
+   };
+
 Example of the node using power domain:
 
node {
diff --git a/arch/arm/mach-exynos/pm_domains.c 
b/arch/arm/mach-exynos/pm_domains.c
index bcd8dcf..41f064b 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -24,6 +25,8 @@
 
 #define INT_LOCAL_PWR_EN   0x7
 
+#define MAX_CLK_PER_DOMAIN 4
+
 /*
  * Exynos specific wrapper around the generic power domain
  */
@@ -32,6 +35,9 @@ struct exynos_pm_domain {
char const *name;
bool is_off;
struct generic_pm_domain pd;
+   struct clk *oscclk;
+   struct clk *clk[MAX_CLK_PER_DOMAIN];
+   struct clk *pclk[MAX_CLK_PER_DOMAIN];
 };
 
 static int exynos_pd_power(struct generic_pm_domain *domain, bool power_on)
@@ -44,6 +50,19 @@ static int exynos_pd_power(struct generic_pm_domain *domain, 
bool power_on)
pd = container_of(domain, struct exynos_pm_domain, pd);
base = pd->base;
 
+   /* Set oscclk before powering off a domain*/
+   if (!power_on) {
+   int i;
+
+   for (i = 0; i < MAX_CLK_PER_DOMAIN; i++) {
+   if (IS_ERR(pd->clk[i]))
+   break;
+   if (clk_set_parent(pd->clk[i], pd->oscclk))
+   pr_err("%s: error setting oscclk as parent to 
clock %d\n",
+   pd->name, i);
+   }
+   }
+
pwr = power_on ? INT_LOCAL_PWR_EN : 0;
__raw_writel(pwr, base);
 
@@ -60,6 +79,20 @@ static int exynos_pd_power(struct generic_pm_domain *domain, 
bool power_on)
cpu_relax();
usleep_range(80, 100);
}
+
+   /* Restore clocks after powering on a domain*/
+   if (power_on) {
+   int i;
+
+   for (i = 0; i < MAX_CLK_PER_DOMAIN; i++) {
+   if (IS_ERR(pd->clk[i]))
+   break;
+   if (clk_set_parent(pd->clk[i], pd->pclk[i]))
+   pr_err("%s: error setting paren

[RESEND PATCHv2 3/3] ARM: dts: Add clock property for mfc_pd in 5420

[Arun Kumar K]

Adding the optional clock property for the mfc_pd for
handling the re-parenting while pd on/off.

Signed-off-by: Arun Kumar K 
Signed-off-by: Shaik Ameer Basha 
Reviewed-by: Tomasz Figa 
---
 arch/arm/boot/dts/exynos5420.dtsi |3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 79e9119..1595722 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -260,6 +260,9 @@
mfc_pd: power-domain@10044060 {
compatible = "samsung,exynos4210-pd";
reg = <0x10044060 0x20>;
+   clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_SW_ACLK333>,
+   <&clock CLK_MOUT_USER_ACLK333>;
+   clock-names = "oscclk", "pclk0", "clk0";
};
 
disp_pd: power-domain@100440C0 {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND PATCHv2 0/3] Power-domain clk handling

[Arun Kumar K]

This patch series for clock handling in power domain is
re-send for merging after rebasing onto latest linux-samsung.git,
for-next branch.
Original series and discussion can be found here:
https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg31550.html

Arun Kumar K (2):
  clk: exynos5420: Add IDs for clocks used in PD mfc
  ARM: dts: Add clock property for mfc_pd in 5420

Prathyush K (1):
  ARM: EXYNOS: Add support for clock handling in power domain

 .../bindings/arm/exynos/power_domain.txt   |   20 +++
 arch/arm/boot/dts/exynos5420.dtsi  |3 +
 arch/arm/mach-exynos/pm_domains.c  |   61 +++-
 drivers/clk/samsung/clk-exynos5420.c   |6 +-
 include/dt-bindings/clock/exynos5420.h |2 +
 5 files changed, 89 insertions(+), 3 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2

[Viresh Kumar]

On 4 July 2014 09:51, Viresh Kumar  wrote:
> Yeah, having something like what you suggested from DT is the perfect
> solution to get over this. The only reason why I am not touching that here
> is to not delay other patches just because of that.
>
> There are separate threads going on for that and probably somebody
> else was trying to push for that.
>
> That's it, nothing more. I would definitely like to use those bindings instead
>  of the crazy routines we are trying here, once that is finalized :)

Do we have some kind of agreement for this temporary solution? Anyways
I will kick the other thread again to resolve the bindings soon.

@Stephen: Do you still want find_rate_changer() stuff in this series only
and or this can go into 3.17 without anymore changes and lets finalize
the bindings Mike suggested and then update this code?

--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] devicetree/bindings: Add binding for micron n25q512a memory

[Priyanka Jain]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, July 08, 2014 2:56 AM
> To: Jain Priyanka-B32167
> Cc: devicetree@vger.kernel.org; linuxppc-...@lists.ozlabs.org; linux-
> s...@vger.kernel.org; linux-...@lists.infradead.org
> Subject: Re: [PATCH] devicetree/bindings: Add binding for micron n25q512a
> memory
> 
> On Thu, 2014-07-03 at 23:08 -0500, Jain Priyanka-B32167 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Friday, July 04, 2014 3:40 AM
> > > To: Jain Priyanka-B32167
> > > Cc: devicetree@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
> > > linux- s...@vger.kernel.org; linux-...@lists.infradead.org
> > > Subject: Re: [PATCH] devicetree/bindings: Add binding for micron
> > > n25q512a memory
> > >
> > > On Thu, 2014-07-03 at 15:42 +0530, Priyanka Jain wrote:
> > > > -Micron n25q512a memory is supported by m25p80 driver.
> > > >  Add compatible field required to support n25q512a in m25p80.txt
> > > > -Add micron to the vendor-prefixes.txt file
> > > >
> > > > Signed-off-by: Priyanka Jain 
> > > > ---
> > > >  Documentation/devicetree/bindings/mtd/m25p80.txt   |1 +
> > > >  .../devicetree/bindings/vendor-prefixes.txt|1 +
> > > >  2 files changed, 2 insertions(+), 0 deletions(-)
> > >
> > > Why did you send this to the ppc list but not the spi or mtd lists?
> > >
> > [Jain Priyanka-B32167] Sorry, I missed that
> > > I'm having a hard time following the flow of how these SPI devices
> > > get bound -- is the compatible involved at all?  I don't see this
> > > string (with vendor prefix included) in the driver.  I do see a
> > > table that contains what looks like device IDs.  If the device can
> > > report its id, shouldn't we rely on that rather than device tree
> compatible?
> > >
> > > -Scott
> > [Jain Priyanka-B32167]
> > Spi driver has a check to device name corresponding to device-id and
> compare to what is passed in dts string.
> 
> Please go into more detail.  I don't see where the string
> "micron,n25q512a" appears in the current kernel.  I do see "n25q512a",
> but how does that compare successfully with the version of the string
> that has a vendor compatible?
> 
> Again, is there a device ID that can be read at runtime?  Is there a
> compatible string that represents a common programming interface?
[Jain Priyanka-B32167] 
Spi driver (of_register_spi_devices()) search for compatible string in 
device-tree. It selects the flash device driver based on the compatible string 
(n25q512a). This compatible string is essential, else device probe wont 
continue.  Then Device-id of flash is read at runtime in probe and compared 
with the corresponding device-id of flash (n25q512a). Device-id (maintained as 
first element in INFO string in spi_nor_ids[] in drivers/mtd/spi-nor/spi-nor.c 
file)
Only if both device-ids match, the device is taken as successfully detected.
Regarding vendor "micron", you are right currently the vendor information is 
not maintained as such in device-id, but the convention that is followed for 
compatible string is "vendor-id, device-id"
> 
> > New checkpatch script search for exact string match in binding folder.
> So, I have added this in example.
> 
> That check has a lot of false positives when it comes to compatible
> strings for specific chips that don't need to be specifically mentioned
> in a more generic binding.
> 
> -Scott
> 
[Jain Priyanka-B32167] Even though "micron,n25q512a" is in sync with binding 
mentioned in " Documentation/devicetree/bindings/mtd/m25p80.txt   ", I have to 
add this as an a example, just to avoid checkpatch error. What should be the 
approach going forward: Should such checkpatch warnings be ignored?

Re: [PATCH V8 0/9] PCI: Add SPEAr13xx PCie support

[Viresh Kumar]

On Tue, Jul 8, 2014 at 9:21 AM, Mohit KUMAR DCG  wrote:
> - These patches are rebased over 3-16-rc3 to go through arm-soc tree.
> Somehow we are having 'sync' issue in providing web link for spear public
> repository with these patches.
>
> It will be resolve soon, and I will provide the link.

I can push these to some Linaro repo of mine if you want. And you can
send a pull request from there then.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] devicetree/bindings/powerpc/fsl: Add binding for board

[Priyanka Jain]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, July 08, 2014 3:00 AM
> To: Jain Priyanka-B32167
> Cc: devicetree@vger.kernel.org; linuxppc-...@lists.ozlabs.org
> Subject: Re: [PATCH] devicetree/bindings/powerpc/fsl: Add binding for
> board
> 
> On Mon, 2014-07-07 at 14:06 +0530, Priyanka Jain wrote:
> > Signed-off-by: Priyanka Jain 
> > ---
> >  .../devicetree/bindings/powerpc/fsl/board.txt  |   17
> -
> >  1 files changed, 16 insertions(+), 1 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> > b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> > index f35f295..7800729 100644
> > --- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> > +++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> > @@ -1,8 +1,23 @@
> >  Freescale Reference Board Bindings
> >
> > -This document describes device tree bindings for various devices that
> > +This document describes device tree bindings for board and  various
> > +devices that
> >  exist on some Freescale reference boards.
> >
> > +* Board node
> > +Required properties:
> > +
> > + - model : Should be "fsl,"
> > + - compatible : Should be "fsl,"
> > +   example: "fsl,T1040RDB", "fsl,T1042RDB", "fsl,T1042RDB_PI"
> > +"fsl,T1040QDS", "fsl,T1042QDS"
> > +
> > +Example:
> > +
> > +/ {
> > +   model = "fsl,T1040RDB";
> > +   compatible = "fsl,T1040RDB";
> > +};
> 
> We really don't need to do this for every board just to satisfy
> checkpatch.
> 
> -Scott
> 
[Jain Priyanka-B32167] Is it OK to submit a patch with board checkpatch warning 
for this case ?
N�r��yb�X��ǧv�^�)޺{.n�+���z��z��z)w*jg����ݢj/���z�ޖ��2�ޙ&�)ߡ�a�����G���h��j:+v���w��٥

RE: [PATCH V8 0/9] PCI: Add SPEAr13xx PCie support

[Mohit KUMAR DCG]

Hello Bartlomiej,

> -Original Message-
> From: Bartlomiej Zolnierkiewicz [mailto:b.zolnier...@samsung.com]
> Sent: Monday, July 07, 2014 9:01 PM
> To: Pratyush ANAND
> Cc: Arnd Bergmann (a...@arndb.de); 'Bjorn Helgaas'
> (bhelg...@google.com); Mohit KUMAR DCG; spear-devel; linux-
> ker...@vger.kernel.org; devicetree@vger.kernel.org; linux-
> p...@vger.kernel.org; Mark Nicholson
> Subject: Re: [PATCH V8 0/9] PCI: Add SPEAr13xx PCie support
> 
> 
> Hi Arnd,
> 
> Any update on status of this patchset?  Is it OK for it to go through arm-soc
> tree or should it be splitted into separate parts which would go through
> pci/phy/arm-soc trees?

- These patches are rebased over 3-16-rc3 to go through arm-soc tree.
Somehow we are having 'sync' issue in providing web link for spear public
repository with these patches. 

It will be resolve soon, and I will provide the link.

> 
> [ The patchset applies fine to next-20140707 after fixing trivial
>   reject in drivers/pci/host/Makefile in patch #8.  To make it build
>   the following line from patch #8 needs to be dropped:
> 
>   +   spin_lock_init(&pp->conf_lock);

- yes, I have already considered this while rebasing.

Thanks
Mohit

> ]
> 
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
> 
> On Thursday, May 22, 2014 05:01:19 PM Pratyush Anand wrote:
> > Hi Arnd/Bjorn,
> >
> > On Mon, May 19, 2014 at 07:55:12PM +0800, Mohit KUMAR wrote:
> > > Hello Arnd,
> > >
> > > > -Original Message-
> > > > From: Mohit KUMAR DCG
> > > > Sent: Tuesday, April 15, 2014 5:20 PM
> > > > To: spear-devel; linux-ker...@vger.kernel.org;
> > > > devicetree@vger.kernel.org; linux-...@vger.kernel.org;
> > > > linux-arm-ker...@lists.infradead.org
> > > > Cc: Mohit KUMAR DCG
> > > > Subject: [PATCH V8 0/9] PCI: Add SPEAr13xx PCie support
> > > >
> > > > Patch# 1 and 2: Improvement and fixes for SPEAr13xx support.
> > > > Patch# 3,4 and 6: Add DT bindings for spear1310/40-miphy, misc and
> > > > pcie node Patch# 5: Add spear1310/40-miphy driver and support for
> > > > spear1310/40 miphy wrapper.
> > > > Patch# 7-9: Add SPEAr13xx PCIe driver and dt support.
> > > >
> > > > These pathes are tested with linux-3.15 tag of arm-soc tree.
> > > > Tested with SPEAr1310 evaluation board with:
> > > > - INTEL PRO 100/100 EP card
> > > > - USB xhci gen2 card
> > > > - Above cards connected through LeCROY PTC switch
> > > >
> > > > Modifications for SATA are tested with SPEAr1340-evb board
> > > >
> > >
> > > I think 3.16 windows is about to close, are you planning to merge this
> series?
> > > Pls let me know if something pending on our part.
> >
> > If you could let us know the status of this patch series inclusion.
> >
> > Regards
> > Pratyush
> >
> > >
> > > Regards
> > > Mohit
> > >
> > > > Changes since v7:
> > > > - Rebase over for-linus-3.15 tag of arm-soc tree so that complete
> > > > patch series can be applied cleanly.
> > > > - Incorporated few comments on comment style and superfluous
> > > > comments Changes since v6:
> > > > - Split miphy driver for SPEAr1310 and SPEAr1340
> > > > - Some cleanup and incorporated other minor comments Changes since
> v5:
> > > > - Split DT bindings for misc, miphy-40lp and pcie node into
> > > > sepearte patches
> > > > - Merge config options PCIE_SPEAR13XX and PCI_MSI into defconfig
> > > > patch
> > > > - Incorporated other minor comments Changes since v4:
> > > > - Uses per device function pointers passed from .data field to
> > > >   the of_device_id instead of of_device_is_compatible.
> > > > - Incorporated other minor comments from v4
> > > >
> > > > Changes since v3:
> > > > - Phy driver renamed to phy-miphy40lp
> > > > - ahci phy hook patch used as suggested by Arnd
> > > > - Incorporated other minor comments from v3
> > > >
> > > > Changes since v2:
> > > > - Incorporated comments to move SPEAr13xx PCIe and SATA phy
> > > > specific routines to
> > > >   the phy framework
> > > > - Modify ahci driver to include phy hooks
> > > > - phy-core driver modifications for subsys_initcall()
> > >

Re: [PATCH 0/3] dra7: Add PCIe support

[Pratyush Anand]

On Sat, Jul 5, 2014 at 11:02 PM, Bjorn Helgaas  wrote:
> On Wed, Jun 25, 2014 at 11:26:44PM +0530, Kishon Vijay Abraham I wrote:
>> [1] is split into separate series in order for individual subsystem
>> Maintainers to pick up the patches. This series handles the PCIe
>> support for DRA7.
>>
>> Rebased to 3.16-rc2.
>>
>> [1] -> https://lkml.org/lkml/2014/5/29/258
>>
>> Kishon Vijay Abraham I (3):
>>   PCI: designware: Configuration space should be specified in 'reg'
>>   PCI: designware: use untranslated address while programming ATU
>>   PCI: host: pcie-dra7xx: add support for pcie-dra7xx controller
>
> Mohit, I see your ack for [1/3], but not for [2/3]; are you OK with that,
> too?
>
> Pratyush, you had some questions about [2/3]; are you happy with that one?

OK for me.

~Pratyush
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Tushar Behera]

On 07/08/2014 05:04 AM, Kukjin Kim wrote:
> On 07/01/14 20:59, Tushar Behera wrote:
>> On 06/27/2014 08:18 PM, Kevin Hilman wrote:
>>> On Fri, Jun 27, 2014 at 7:18 AM, Kevin Hilman 
>>> wrote:
 On Thu, Jun 26, 2014 at 8:38 PM, Tushar Behera 
 wrote:

> Would you please provide me the environment setting of your u-boot?
> U-boot environment on my board has been over-written, I would like to
> set it same as yours and try to reproduce the issue at my end. With
> only
> 'sound init', I don't seem to hit this issue anymore.

 Attached is a full boot log using v3.16-rc2 with my patch adding
 CLK_IGNORE_UNUSED to mau_epll and Doug's aclk66_peric patch.  In the
 boot log, you'll see the output of 'printenv' inside u-boot where the
 environment is dumped.
>>>
>>> Oops, I sent you a boot log for the octa board.  Here's the one for
>>> peach-pi with the same kernel (built with upstream exynos_defconfig)
>>>
>>> Kevin
>>>
>>
>> The u-boot version is a little different on my Peach-Pi as compared to
>> the market release version. Not sure if that is making any difference.
>>
>> Peach # version
>>
>> U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
>> armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
>> 4.8.x-google 20130905 (prerelease)
>> GNU ld (binutils-2.22_cos_gg_2) 2.22
>>
> 
> Note that I've applied this only from this series so I'm not sure how
> much the problem can be solved...any updates for 1/3 and 3/3?
> 
> - Kukjin

Thanks for applying 2/3. I am working on 1/3 to see if we are following
the right approach to fix Kevin's issue (unfortunately, I am not hitting
the bug on my board ATM). 3/3 has already been merged through a
different patchset.

-- 
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/2] spi: add driver for Rockchip RK3xxx SoCs integrated SPI

[Addy Ke]

In order to facilitate understanding, rockchip SPI controller IP design
looks similar in its registers to designware. But IC implementation
is different from designware, So we need a dedicated driver for Rockchip
RK3XXX SoCs integrated SPI. The main differences:

- dma request line: rockchip SPI controller have two DMA request line
  for tx and rx.

- Register offset:
  RK3288DW

  SPI_CTRLR0  0x0x
  SPI_CTRLR1  0x00040x0004
  SPI_SSIENR  0x00080x0008
  SPI_MWCRNONE  0x000c
  SPI_SER 0x000c0x0010
  SPI_BAUDR   0x00100x0014
  SPI_TXFTLR  0x00140x0018
  SPI_RXFTLR  0x00180x001c
  SPI_TXFLR   0x001c0x0020
  SPI_RXFLR   0x00200x0024
  SPI_SR  0x00240x0028
  SPI_IPR 0x0028NONE
  SPI_IMR 0x002c0x002c
  SPI_ISR 0x00300x0030
  SPI_RISR0x00340x0034
  SPI_TXOICR  NONE  0x0038
  SPI_RXOICR  NONE  0x003c
  SPI_RXUICR  NONE  0x0040
  SPI_MSTICR  NONE  0x0044
  SPI_ICR 0x00380x0048
  SPI_DMACR   0x003c0x004c
  SPI_DMATDLR 0x00400x0050
  SPI_DMARDLR 0x00440x0054
  SPI_TXDR0x0400NONE
  SPI_RXDR0x0800NONE
  SPI_IDR NONE  0x0058
  SPI_VERSION NONE  0x005c
  SPI_DR  NONE  0x0060

- register configuration:
  RK3288  DW
  - SPI_CTROL0:
control frame sizebit[5:2]bit[15:12]
shift register loop   NONEbit[11]
transfer mode bit[19:18]  bit[9:8]
frame format  bit[17:16]  bit[5:4]
data frame size   bit[1:0]bit[3:0]
 
  For more information, see RK3288 chip manual.

- Wait for idle: Must ensure that the FIFO data has been sent out
  before the next transfer.

Signed-off-by: Addy Ke 
---
changes since v1:
- more specific about the differences according to comments from Mark Brown
- not to cast away "const" according to comments from Mark Brown
- add set_cs() operation provided to the core
- change rockchip_spi_hw_init() to get_fifo_len() 
- remove spi_setup() and spi_clean() operations
- remove wait_for_dma(), replaced by calling spi_finalize_current_transfer() 
when done
- remove wait_for_not_busy(), replaced by setting xfer->delay_usecs
- remove interrupt handler
- call clk_disable_unprepare() if spi_master_resume() failed

changes since v2:
- Kconfig: add "depends on (ARCH_ROCKCHIP || COMPILE_TEST)" for SPI_ROCKCHIP
- use wait_for_idle and do not set xfer->delay_uses suggested by Mark Brown
- master->mode_bits: remove SPI_CS_HIGH bit, according to comments from Jonas 
Gorski
- remove some log information suggested by Mark Brown
- remove Unneeded semicolon
- add compatible strings for RK3188 and RK3288
- improve differences between RK3288 and DW, provided by IC engineer. 
- fixed some warning checked by "./scripts/checkpatch.pl --strict"

 drivers/spi/Kconfig|  12 +
 drivers/spi/Makefile   |   1 +
 drivers/spi/spi-rockchip.c | 837 +
 3 files changed, 850 insertions(+)
 create mode 100644 drivers/spi/spi-rockchip.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 60f2b41..c4e307b 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -375,6 +375,18 @@ config SPI_PXA2XX
 config SPI_PXA2XX_PCI
def_tristate SPI_PXA2XX && PCI
 
+config SPI_ROCKCHIP
+   tristate "Rockchip SPI controller driver"
+   depends on (ARCH_ROCKCHIP || COMPILE_TEST)
+   help
+ This selects a driver for Rockchip SPI controller.
+
+ If you say yes to this option, support will be included for
+ RK3066, RK3188 and RK3288 families of SPI controller.
+ Rockchip SPI controller support DMA transport and PIO mode.
+ The main usecase of this controller is to use spi flash as boot
+ device.
+
 config SPI_RSPI
tristate "Renesas RSPI/QSPI controller"
depends on (SUPERH && SH_DMAE_BASE) || ARCH_SHMOBILE
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index bd79266..361fbf3 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -60,6 +60,7 @@ spi-pxa2xx-platform-$(CONFIG_SPI_PXA2XX_DMA)  += 
spi-pxa2xx-dma.o
 obj-$(CONFIG_SPI_PXA2XX)   += spi-pxa2xx-platform.o
 obj-$(CONFIG_SPI_PXA2XX_PCI)   += spi-pxa2xx-pci.o
 obj-$(CONFIG_SPI_QUP)  += spi-qup.o
+obj-$(CONFIG_SPI_ROCKCHIP) += spi-rockchip.o
 obj-$(CONFIG_SPI_RSPI) += spi-rspi.o
 obj-$(CONFIG_SPI_S3C24XX)  += spi-s3c24xx-hw.o
 spi-s3c24xx-hw-y   := spi-s3c24xx.o
diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
new file mode 100644
index 000..488a7b8
--- /dev/null
+++ b/drivers/spi/spi-rockchip.c
@@ -0,0 +1,837 @@
+/*
+ * Copyright (c) 2014, F

[PATCH RESEND] ARM: dts: Restructure imx6qdl-wandboard.dtsi for new rev C1 board.

[George Joseph]

The rev C1 Wandboard uses the Broadcom 4330 for WiFi and Bluetooth instead of
the 4329.  This changes the PADS assigned for the control lines.  Another
side effect of the change is that on the rev C1 board, usdhc driver can't
detect the chip presence correctly so usdhc2 now needs its 'non-removeable'
property removed.

So that rev B1 and earlier can continue to work, this patch splits the
board-specific definitions from imx6qdl-wandboard.dtsi into
imx6qdl-wandboard-revb1.dtsi and imx6qdl-wandboard-revc1.dtsi.  The new files
include the original base imx6qdl-wandboard.dtsi which retains the common
definitions.

The existing imx6dl-wandboard.dts includes imx6qdl-wandboard-revc1.dtsi and
imx6dl-wandboard-revb1.dts (new) includes imx6qdl-wandboard-revb1.dtsi.
This makes the rev C1 board the new default.  The same pattern is used for
imx6q-wandboard.dts.

So, from U-Boot on a WB-Quad you use imxq-wandboard-revb1.dtb for the older B1
board and imxq-wandboard.dtb for the current rev C1 board.

Signed-off-by: George Joseph 
---
 arch/arm/boot/dts/imx6dl-wandboard-revb1.dts   | 22 ++
 arch/arm/boot/dts/imx6dl-wandboard.dts |  2 +-
 arch/arm/boot/dts/imx6q-wandboard-revb1.dts| 26 
 arch/arm/boot/dts/imx6q-wandboard.dts  |  2 +-
 arch/arm/boot/dts/imx6qdl-wandboard-revb1.dtsi | 39 
 arch/arm/boot/dts/imx6qdl-wandboard-revc1.dtsi | 41 ++
 arch/arm/boot/dts/imx6qdl-wandboard.dtsi   | 21 -
 7 files changed, 130 insertions(+), 23 deletions(-)

diff --git a/arch/arm/boot/dts/imx6dl-wandboard-revb1.dts
b/arch/arm/boot/dts/imx6dl-wandboard-revb1.dts
new file mode 100644
index 000..f607d4f
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-wandboard-revb1.dts
@@ -0,0 +1,22 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Author: Fabio Estevam 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+/dts-v1/;
+#include "imx6dl.dtsi"
+#include "imx6qdl-wandboard-revb1.dtsi"
+
+/ {
+ model = "Wandboard i.MX6 Dual Lite Board";
+ compatible = "wand,imx6dl-wandboard", "fsl,imx6dl";
+
+ memory {
+ reg = <0x1000 0x4000>;
+ };
+};
diff --git a/arch/arm/boot/dts/imx6dl-wandboard.dts
b/arch/arm/boot/dts/imx6dl-wandboard.dts
index e672891..bbb6167 100644
--- a/arch/arm/boot/dts/imx6dl-wandboard.dts
+++ b/arch/arm/boot/dts/imx6dl-wandboard.dts
@@ -10,7 +10,7 @@
  */
 /dts-v1/;
 #include "imx6dl.dtsi"
-#include "imx6qdl-wandboard.dtsi"
+#include "imx6qdl-wandboard-revc1.dtsi"

 / {
  model = "Wandboard i.MX6 Dual Lite Board";
diff --git a/arch/arm/boot/dts/imx6q-wandboard-revb1.dts
b/arch/arm/boot/dts/imx6q-wandboard-revb1.dts
new file mode 100644
index 000..20bf3c2
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-wandboard-revb1.dts
@@ -0,0 +1,26 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Author: Fabio Estevam 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+/dts-v1/;
+#include "imx6q.dtsi"
+#include "imx6qdl-wandboard-revb1.dtsi"
+
+/ {
+ model = "Wandboard i.MX6 Quad Board";
+ compatible = "wand,imx6q-wandboard", "fsl,imx6q";
+
+ memory {
+ reg = <0x1000 0x8000>;
+ };
+};
+
+&sata {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6q-wandboard.dts
b/arch/arm/boot/dts/imx6q-wandboard.dts
index 36be17f..4a8a6ee 100644
--- a/arch/arm/boot/dts/imx6q-wandboard.dts
+++ b/arch/arm/boot/dts/imx6q-wandboard.dts
@@ -10,7 +10,7 @@
  */
 /dts-v1/;
 #include "imx6q.dtsi"
-#include "imx6qdl-wandboard.dtsi"
+#include "imx6qdl-wandboard-revc1.dtsi"

 / {
  model = "Wandboard i.MX6 Quad Board";
diff --git a/arch/arm/boot/dts/imx6qdl-wandboard-revb1.dtsi
b/arch/arm/boot/dts/imx6qdl-wandboard-revb1.dtsi
new file mode 100644
index 000..e44d982
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-wandboard-revb1.dtsi
@@ -0,0 +1,39 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Author: Fabio Estevam 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include "imx6qdl-wandboard.dtsi"
+
+&iomuxc {
+ pinctrl-0 = <&pinctrl_hog>;
+
+ imx6qdl-wandboard {
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x130b0 /* GPIO_0_CLKO */
+ MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x8000 /* uSDHC1 CD */
+ MX6QDL_PAD_EIM_DA9__GPIO3_IO09 0x8000 /* uSDHC3 CD */
+ MX6QDL_PAD_EIM_EB1__GPIO2_IO29 0x8000 /* WL_REF_ON */
+ MX6QDL_PAD_EIM_A25__GPIO5_IO02 0x8000 /* WL_RST_N */
+ MX6QDL_PAD_ENET_RXD1__GPIO1_IO26 0x8000 /* WL_REG_ON */
+ MX6QDL_PAD_ENET_TXD1__GPIO1_IO29 0x8000 /* WL_HOST_WAKE */
+ MX6QDL_PAD_ENET_TXD0__GP

[PATCH 3/3] pinctrl: Introduce pinctrl driver for Qualcomm pm8xxx

[Bjorn Andersson]

This introduces a pinctrl, pinconf, pinmux and gpio driver for the gpio
block found in pm8018, pm8038, pm8058, pm8917 and pm8921 pmics from
Qualcomm.

Signed-off-by: Bjorn Andersson 
---
 drivers/pinctrl/Kconfig   |   11 +
 drivers/pinctrl/Makefile  |1 +
 drivers/pinctrl/pinctrl-pm8xxx-gpio.c |  796 +
 3 files changed, 808 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-pm8xxx-gpio.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 0042ccb..c173db6 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -278,6 +278,17 @@ config PINCTRL_DB8540
bool "DB8540 pin controller driver"
depends on PINCTRL_NOMADIK && ARCH_U8500
 
+config PINCTRL_PM8XXX_GPIO
+   tristate "Qualcomm PM8xxx gpio driver"
+   depends on GPIOLIB && OF && (ARCH_QCOM || COMPILE_TEST)
+   select PINCONF
+   select PINMUX
+   select GENERIC_PINCONF
+   help
+ This is the pinctrl, pinmux, pinconf and gpiolib driver for the
+ Qualcomm GPIO blocks found in the pm8018, pm8038, pm8058, pm8917 and
+ pm8921 pmics from Qualcomm.
+
 config PINCTRL_ROCKCHIP
bool
select PINMUX
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index c4b5d40..806f6ad 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_PINCTRL_STN8815) += pinctrl-nomadik-stn8815.o
 obj-$(CONFIG_PINCTRL_DB8500)   += pinctrl-nomadik-db8500.o
 obj-$(CONFIG_PINCTRL_DB8540)   += pinctrl-nomadik-db8540.o
 obj-$(CONFIG_PINCTRL_PALMAS)   += pinctrl-palmas.o
+obj-$(CONFIG_PINCTRL_PM8XXX_GPIO)  += pinctrl-pm8xxx-gpio.o
 obj-$(CONFIG_PINCTRL_ROCKCHIP) += pinctrl-rockchip.o
 obj-$(CONFIG_PINCTRL_SINGLE)   += pinctrl-single.o
 obj-$(CONFIG_PINCTRL_SIRF) += sirf/
diff --git a/drivers/pinctrl/pinctrl-pm8xxx-gpio.c 
b/drivers/pinctrl/pinctrl-pm8xxx-gpio.c
new file mode 100644
index 000..5aaf914
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-pm8xxx-gpio.c
@@ -0,0 +1,796 @@
+/*
+ * Copyright (c) 2014, Sony Mobile Communications AB.
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "core.h"
+#include "pinconf.h"
+#include "pinctrl-utils.h"
+
+/* direction */
+#define PM8XXX_GPIO_DIR_OUTBIT(0)
+#define PM8XXX_GPIO_DIR_IN BIT(1)
+
+/* output buffer */
+#define PM8XXX_GPIO_PUSH_PULL  0
+#define PM8XXX_GPIO_OPEN_DRAIN 1
+
+/* bias */
+#define PM8XXX_GPIO_BIAS_PU_30 0
+#define PM8XXX_GPIO_BIAS_PU_1P51
+#define PM8XXX_GPIO_BIAS_PU_31P5   2
+#define PM8XXX_GPIO_BIAS_PU_1P5_30 3
+#define PM8XXX_GPIO_BIAS_PD4
+#define PM8XXX_GPIO_BIAS_NP5
+
+/* GPIO registers */
+#define SSBI_REG_ADDR_GPIO_BASE0x150
+#define SSBI_REG_ADDR_GPIO(n)  (SSBI_REG_ADDR_GPIO_BASE + n)
+
+#define PM8XXX_GPIO_WRITE  BIT(7)
+
+#define PM8XXX_MAX_GPIOS   44
+
+struct pm8xxx_gpio_pin {
+   int irq;
+
+   u8 power_source;
+   u8 direction;
+   u8 output_buffer;
+   u8 output_value;
+   u8 bias;
+   u8 output_strength;
+   u8 disable;
+   u8 function;
+   u8 non_inverted;
+};
+
+struct pm8xxx_gpio_data {
+   int ngpio;
+   const int *power_sources;
+   int npower_sources;
+};
+
+struct pm8xxx_gpio {
+   struct device *dev;
+   struct regmap *regmap;
+   struct pinctrl_dev *pctrl;
+   struct gpio_chip chip;
+
+   const struct pm8xxx_gpio_data *data;
+
+   struct pm8xxx_gpio_pin pins[PM8XXX_MAX_GPIOS];
+};
+
+static const char * const pm8xxx_gpio_groups[PM8XXX_MAX_GPIOS] = {
+   "gpio1", "gpio2", "gpio3", "gpio4", "gpio5", "gpio6", "gpio7", "gpio8",
+   "gpio9", "gpio10", "gpio11", "gpio12", "gpio13", "gpio14", "gpio15",
+   "gpio16", "gpio17", "gpio18", "gpio19", "gpio20", "gpio21", "gpio22",
+   "gpio23", "gpio24", "gpio25", "gpio26", "gpio27", "gpio28", "gpio29",
+   "gpio30", "gpio31", "gpio32", "gpio33", "gpio34", "gpio35", "gpio36",
+   "gpio37", "gpio38", "gpio39", "gpio40", "gpio41", "gpio42", "gpio43",
+   "gpio44",
+};
+
+static const char * const pm8xxx_gpio_functions[] = {
+   "normal", "paired",
+   "func1", "func2",
+   "dtest1", "dtest2", "dtest3", "dtest4",
+};
+
+static int pm8xxx_gpio_read(struct pm8xxx_gpio *pct

[PATCH 2/3] pinctrl: Device tree bindings for Qualcomm pm8xxx gpio block

[Bjorn Andersson]

This introduced the device tree bindings for the gpio block found in
pm8018, pm8038, pm8058, pm8917 and pm8921 pmics from Qualcomm.

Signed-off-by: Bjorn Andersson 
---
 .../bindings/pinctrl/qcom,pm8xxx-gpio.txt  |  230 
 include/dt-bindings/pinctrl/qcom,pm8xxx-gpio.h |   34 +++
 2 files changed, 264 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/qcom,pm8xxx-gpio.txt
 create mode 100644 include/dt-bindings/pinctrl/qcom,pm8xxx-gpio.h

diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pm8xxx-gpio.txt 
b/Documentation/devicetree/bindings/pinctrl/qcom,pm8xxx-gpio.txt
new file mode 100644
index 000..0035dd8
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,pm8xxx-gpio.txt
@@ -0,0 +1,230 @@
+Qualcomm PM8XXX GPIO block
+
+This binding describes the GPIO block(s) found in the 8xxx series of pmics from
+Qualcomm.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,pm8018-gpio"
+   "qcom,pm8038-gpio"
+   "qcom,pm8058-gpio"
+   "qcom,pm8917-gpio"
+   "qcom,pm8921-gpio"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: Register base of the gpio block
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: Must contain an array of encoded interrupt specifiers for
+   each available gpio
+
+- gpio-controller:
+   Usage: required
+   Value type: 
+   Definition: Mark the device node as a GPIO controller
+
+- #gpio-cells:
+   Usage: required
+   Value type: 
+   Definition: Must be 2;
+   the first cell will be used to define gpio number and the
+   second denotes the flags for this gpio
+
+Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
+a general description of GPIO and interrupt bindings.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+The pin configuration nodes act as a container for an abitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin or a list of pins. This configuration can include the
+mux function to select on those pin(s), and various pin configuration
+parameters, s listed below.
+
+
+SUBNODES:
+
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+
+Each subnode only affects those parameters that are explicitly listed. In
+other words, a subnode that lists a mux function but no pin configuration
+parameters implies no information about any pin configuration parameters.
+Similarly, a pin subnode that describes a pullup parameter implies no
+information about e.g. the mux function.
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pin configuration subnode:
+
+- pins:
+   Usage: required
+   Value type: 
+   Definition: List of gpio pins affected by the properties specified in
+   this subnode.  Valid pins are:
+   gpio1-gpio6 for pm8018
+   gpio1-gpio12 for pm8038
+   gpio1-gpio40 for pm8058
+   gpio1-gpio38 for pm8917
+   gpio1-gpio44 for pm8921
+
+- function:
+   Usage: optional
+   Value type: 
+   Definition: Specify the alternative function to be configured for the
+   specified pins.  Valid values are:
+   "normal",
+   "paired",
+   "func1",
+   "func2",
+   "dtest1",
+   "dtest2",
+   "dtest3",
+   "dtest4"
+
+- bias-disable:
+   Usage: optional
+   Value type: 
+   Definition: The specified pins should be configued as no pull.
+
+- bias-pull-down:
+   Usage: optional
+   Value type: 
+   Definition: The specified pins should be configued as pull down.
+
+- bias-pull-up:
+   Usage: optional
+   Value type:  (optional)
+   Definition: The specified pins should be configued as pull up. An
+   optional argument can be used to configure the strength.
+   Valid values are; as defined in
+   :
+   1: 30uA (PM8XXX_GPIO_PULL_UP_30)
+   2: 1.5uA(PM8XXX_GPIO_PULL_UP_1P5)
+   3: 31.5uA   (PM8XXX_GPIO_PULL_UP_31P5)
+   4: 1.5uA + 30uA boost   (PM8XXX_GPIO_PULL_UP_1P5_30)
+
+- bias-high-impedance:
+   Usage: optional
+   Value type: 
+   Definition: The specified pins will put in hig

[PATCH 1/3] mfd: pm8921: Expose pm8xxx_read_irq_status

[Bjorn Andersson]

Most status bits, e.g. for GPIO and MPP input, is retrieved by reading
the interrupt status registers, so this needs to be exposed to clients.

Signed-off-by: Bjorn Andersson 
---
 drivers/mfd/pm8921-core.c   |   36 
 include/linux/mfd/pm8921-core.h |   32 
 2 files changed, 68 insertions(+)
 create mode 100644 include/linux/mfd/pm8921-core.h

diff --git a/drivers/mfd/pm8921-core.c b/drivers/mfd/pm8921-core.c
index 9595138..7dda0c2 100644
--- a/drivers/mfd/pm8921-core.c
+++ b/drivers/mfd/pm8921-core.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #defineSSBI_REG_ADDR_IRQ_BASE  0x1BB
 
@@ -65,6 +66,41 @@ struct pm_irq_chip {
u8  config[0];
 };
 
+int pm8xxx_read_irq_status(int irq)
+{
+   struct irq_data *d = irq_get_irq_data(irq);
+   struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
+   unsigned int pmirq = irqd_to_hwirq(d);
+   unsigned int bits;
+   int irq_bit;
+   u8 block;
+   int rc;
+
+   if (!chip) {
+   pr_err("Failed to resolve pm_irq_chip\n");
+   return -EINVAL;
+   }
+
+   block = pmirq / 8;
+   irq_bit = pmirq % 8;
+
+   spin_lock(&chip->pm_irq_lock);
+   rc = regmap_write(chip->regmap, SSBI_REG_ADDR_IRQ_BLK_SEL, block);
+   if (rc) {
+   pr_err("Failed Selecting Block %d rc=%d\n", block, rc);
+   goto bail;
+   }
+
+   rc = regmap_read(chip->regmap, SSBI_REG_ADDR_IRQ_RT_STATUS, &bits);
+   if (rc)
+   pr_err("Failed Reading Status rc=%d\n", rc);
+bail:
+   spin_unlock(&chip->pm_irq_lock);
+
+   return rc ? rc : !!(bits & BIT(irq_bit));
+}
+EXPORT_SYMBOL(pm8xxx_read_irq_status);
+
 static int pm8xxx_read_block_irq(struct pm_irq_chip *chip, unsigned int bp,
 unsigned int *ip)
 {
diff --git a/include/linux/mfd/pm8921-core.h b/include/linux/mfd/pm8921-core.h
new file mode 100644
index 000..77f7cb5
--- /dev/null
+++ b/include/linux/mfd/pm8921-core.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (c) 2014, Sony Mobile Communications AB
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __MFD_PM8921_CORE_H
+#define __MFD_PM8921_CORE_H
+
+#include 
+
+#ifdef CONFIG_MFD_PM8921_CORE
+
+int pm8xxx_read_irq_status(int irq);
+
+#else
+
+static inline int pm8xxx_read_irq_status(int irq)
+{
+   return -ENOSYS;
+}
+
+#endif
+
+#endif
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] Qualcomm pm8xxx gpio driver

[Bjorn Andersson]

This is device tree bindings as well as a driver for the gpio blocks found in
Qualcomm pm8018, pm8038, pm8058, pm8917 and pm8921 pmic chips.

The first patch extends the pm8921-core to expose a function to read out the
"RT status" of an interrupt pin. This is the way input many input values are
exposed in these set of pmics.

Bjorn Andersson (3):
  mfd: pm8921: Expose pm8xxx_read_irq_status
  pinctrl: Device tree bindings for Qualcomm pm8xxx gpio block
  pinctrl: Introduce pinctrl driver for Qualcomm pm8xxx

 .../bindings/pinctrl/qcom,pm8xxx-gpio.txt  |  230 ++
 drivers/mfd/pm8921-core.c  |   36 +
 drivers/pinctrl/Kconfig|   11 +
 drivers/pinctrl/Makefile   |1 +
 drivers/pinctrl/pinctrl-pm8xxx-gpio.c  |  795 
 include/dt-bindings/pinctrl/qcom,pm8xxx-gpio.h |   34 +
 include/linux/mfd/pm8921-core.h|   32 +
 7 files changed, 1139 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/qcom,pm8xxx-gpio.txt
 create mode 100644 drivers/pinctrl/pinctrl-pm8xxx-gpio.c
 create mode 100644 include/dt-bindings/pinctrl/qcom,pm8xxx-gpio.h
 create mode 100644 include/linux/mfd/pm8921-core.h

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 4/6] pci: Introduce a domain number for pci_host_bridge.

[Bjorn Helgaas]

On Fri, Jul 4, 2014 at 8:57 AM, Liviu Dudau  wrote:
> On Mon, Apr 07, 2014 at 11:44:51PM +0100, Bjorn Helgaas wrote:
>> On Mon, Apr 7, 2014 at 4:07 AM, Liviu Dudau  wrote:
>> > On Mon, Apr 07, 2014 at 10:14:18AM +0100, Benjamin Herrenschmidt wrote:
>> >> On Mon, 2014-04-07 at 09:46 +0100, Liviu Dudau wrote:
>> >> >
>> >> > *My* strategy is to get rid of pci_domain_nr(). I don't see why we need
>> >> > to have arch specific way of providing the number, specially after 
>> >> > looking
>> >> > at the existing implementations that return a value from a variable that
>> >> > is never touched or incremented. My guess is that pci_domain_nr() was
>> >> > created to work around the fact that there was no domain_nr 
>> >> > maintainance in
>> >> > the generic code.
>> >>
>> >> Well, there was no generic host bridge structure. There is one now, it 
>> >> should
>> >> go there.
>> >
>> > Exactly! Hence my patch. After it gets accepted I will go through 
>> > architectures
>> > and remove their version of pci_domain_nr().
>>
>> Currently the arch has to supply pci_domain_nr() because that's the
>> only way for the generic code to learn the domain.  After you add
>> pci_create_root_bus_in_domain(), the arch can supply the domain that
>> way, and we won't need the arch-specific pci_domain_nr().  Right?
>> That makes more sense to me; thanks for the explanation.
>>
>> Let me try to explain my concern about the
>> pci_create_root_bus_in_domain() interface.  We currently have these
>> interfaces:
>>
>>   pci_scan_root_bus()
>>   pci_scan_bus()
>>   pci_scan_bus_parented()
>>   pci_create_root_bus()
>>
>> pci_scan_root_bus() is a higher-level interface than
>> pci_create_root_bus(), so I'm trying to migrate toward it because it
>> lets us remove a little code from the arch, e.g., pci_scan_child_bus()
>> and pci_bus_add_devices().
>>
>> I think we can only remove the arch-specific pci_domain_nr() if that
>> arch uses pci_create_root_bus_in_domain().  When we convert an arch
>> from using scan_bus interfaces to using
>> pci_create_root_bus_in_domain(), we will have to move the rest of the
>> scan_bus code (pci_scan_child_bus(), pci_bus_add_devices()) back into
>> the arch code.
>>
>> One alternative is to add an _in_domain() variant of each of these
>> interfaces, but that doesn't seem very convenient either.  My idea of
>> passing in a structure would also require adding variants, so there's
>> not really an advantage there, but I am thinking of the next
>> unification effort, e.g., for NUMA node info.  I don't really want to
>> have to change all the _in_domain() interfaces to also take yet
>> another parameter for the node number.
>
> ...
> My understanding is that when pci_host_bridge structure was introduced
> you were trying to keep the APIs unchanged and hence the creation of a
> bridge was hidden inside the pci_create_root_bus() function.

You mean pci_alloc_host_bridge()?  Right; ideally I would have used
pci_scan_root_bus() everywhere and gotten rid of pci_create_root_bus().
The outline of pci_scan_root_bus() is:

pci_create_root_bus()
pci_scan_child_bus()
pci_bus_add_devices()

The problem was that several arches do interesting things scattered among
that core.  The ACPI host bridge driver used on x86 and ia64 does resource
allocation before pci_bus_add_devices(), as does parisc.  Probably all
arches should do this, but they don't.

And powerpc and sparc use of_scan_bus() or something similar instead of
pci_scan_child_bus().  They probably *could* provide config space accessors
that talk to OF and would allow pci_scan_child_bus() to work.  But that
seemed like too much work at the time.

> If we want to store the domain_nr information in the host bridge structure,
> together with a pointer to sysdata, then we need to break up the creation
> of the pci_host_bridge from the creation of a root bus. At that moment,
> pci_scan_root_bus() will need to be changed to accept a pci_host_bridge
> pointer, while pci_scan_bus() and pci_scan_bus_parented() will create
> the host bridge in the body of their function.

It's hard to change an existing interface like pci_scan_root_bus() because
it's called from so many places and you have to change them all at once.
Then if something goes wrong, the revert makes a mess for everybody.  But
I think it makes sense to add a new interface that does what you want.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 8/9] pci: Add support for creating a generic host_bridge from device tree

[Bjorn Helgaas]

On Tue, Jul 01, 2014 at 07:43:33PM +0100, Liviu Dudau wrote:
> Several platforms use a rather generic version of parsing
> the device tree to find the host bridge ranges. Move the common code
> into the generic PCI code and use it to create a pci_host_bridge
> structure that can be used by arch code.
> 
> Based on early attempts by Andrew Murray to unify the code.
> Used powerpc and microblaze PCI code as starting point.
> 
> Signed-off-by: Liviu Dudau 
> Tested-by: Tanmay Inamdar 
> ---
>  drivers/of/of_pci.c   | 135 
> ++
>  drivers/pci/host-bridge.c |  18 +++
>  include/linux/of_pci.h|  10 
>  include/linux/pci.h   |   8 +++
>  4 files changed, 171 insertions(+)
> 
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 8481996..55d8320 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -89,6 +89,141 @@ int of_pci_parse_bus_range(struct device_node *node, 
> struct resource *res)
>  }
>  EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
>  
> +/**
> + * pci_host_bridge_of_get_ranges - Parse PCI host bridge resources from DT
> + * @dev: device node of the host bridge having the range property
> + * @resources: list where the range of resources will be added after DT 
> parsing
> + * @io_base: pointer to a variable that will contain the physical address for
> + * the start of the I/O range.
> + *
> + * It is the callers job to free the @resources list if an error is returned.
> + *
> + * This function will parse the "ranges" property of a PCI host bridge device
> + * node and setup the resource mapping based on its content. It is expected
> + * that the property conforms with the Power ePAPR document.
> + *
> + * Each architecture is then offered the chance of applying their own
> + * filtering of pci_host_bridge_windows based on their own restrictions by
> + * calling pcibios_fixup_bridge_ranges(). The filtered list of windows
> + * can then be used when creating a pci_host_bridge structure.
> + */
> +static int pci_host_bridge_of_get_ranges(struct device_node *dev,
> + struct list_head *resources, resource_size_t *io_base)
> +{
> + struct resource *res;
> + struct of_pci_range range;
> + struct of_pci_range_parser parser;
> + int err;
> +
> + pr_info("PCI host bridge %s ranges:\n", dev->full_name);
> +
> + /* Check for ranges property */
> + err = of_pci_range_parser_init(&parser, dev);
> + if (err)
> + return err;
> +
> + pr_debug("Parsing ranges property...\n");
> + for_each_of_pci_range(&parser, &range) {
> + /* Read next ranges element */
> + pr_debug("pci_space: 0x%08x pci_addr:0x%016llx 
> cpu_addr:0x%016llx size:0x%016llx\n",
> + range.pci_space, range.pci_addr, range.cpu_addr, 
> range.size);

If you're not trying to match other printk formats, you could try to match
the %pR format used elsewhere, e.g., "%#010llx-%#010llx" with
range.cpu_addr, range.cpu_addr + range.size - 1.

> +
> + /*
> +  * If we failed translation or got a zero-sized region
> +  * then skip this range
> +  */
> + if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
> + continue;
> +
> + res = kzalloc(sizeof(struct resource), GFP_KERNEL);
> + if (!res)
> + return -ENOMEM;
> +
> + err = of_pci_range_to_resource(&range, dev, res);
> + if (err)
> + return err;
> +
> + if (resource_type(res) == IORESOURCE_IO)
> + *io_base = range.cpu_addr;
> +
> + pci_add_resource_offset(resources, res,
> + res->start - range.pci_addr);
> + }
> +
> + /* Apply architecture specific fixups for the ranges */
> + return pcibios_fixup_bridge_ranges(resources);
> +}
> +
> +static atomic_t domain_nr = ATOMIC_INIT(-1);
> +
> +/**
> + * of_create_pci_host_bridge - Create a PCI host bridge structure using
> + * information passed in the DT.
> + * @parent: device owning this host bridge
> + * @ops: pci_ops associated with the host controller
> + * @host_data: opaque data structure used by the host controller.
> + *
> + * returns a pointer to the newly created pci_host_bridge structure, or
> + * NULL if the call failed.
> + *
> + * This function will try to obtain the host bridge domain number by
> + * using of_alias_get_id() call with "pci-domain" as a stem. If that
> + * fails, a local allocator will be used that will put each host bridge
> + * in a new domain.
> + */
> +struct pci_host_bridge *
> +of_create_pci_host_bridge(struct device *parent, struct pci_ops *ops, void 
> *host_data)
> +{
> + int err, domain, busno;
> + struct resource *bus_range;
> + struct pci_bus *root_bus;
> + struct pci_host_bridge *bridge;
> + resource_size_t io_base;
> + LIST_HEAD(res);
> +
> + bus_range = kzalloc(s

Re: [PATCH v8 6/9] pci: Introduce a domain number for pci_host_bridge.

[Bjorn Helgaas]

On Tue, Jul 01, 2014 at 07:43:31PM +0100, Liviu Dudau wrote:
> Make it easier to discover the domain number of a bus by storing
> the number in pci_host_bridge for the root bus. Several architectures
> have their own way of storing this information, so it makes sense
> to try to unify the code. While at this, add a new function that
> creates a root bus in a given domain and make pci_create_root_bus()
> a wrapper around this function.

"While at this" is always a good clue that maybe something should be
split into a separate patch :)  This is a very good example, since it
adds a new interface that deserves its own changelog.

> Signed-off-by: Liviu Dudau 
> Tested-by: Tanmay Inamdar 
> ---
>  drivers/pci/probe.c | 41 +
>  include/linux/pci.h |  4 
>  2 files changed, 37 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 2c92662..abf5e82 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1748,8 +1748,9 @@ void __weak pcibios_remove_bus(struct pci_bus *bus)
>  {
>  }
>  
> -struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
> - struct pci_ops *ops, void *sysdata, struct list_head *resources)
> +struct pci_bus *pci_create_root_bus_in_domain(struct device *parent,
> + int domain, int bus, struct pci_ops *ops, void *sysdata,
> + struct list_head *resources)

I don't think we should do it this way; this makes it possible to have a
host bridge where "bridge->domain_nr != pci_domain_nr(bridge->bus)".

I wonder if it would help to make a weak pci_domain_nr() function that
returns "bridge->domain_nr".  Then each arch could individually drop its
pci_domain_nr() definition as it was converted, e.g., something like this:

  - Convert every arch pci_domain_nr() from a #define to a non-inline
function
  - Add bridge.domain_nr, initialized from pci_domain_nr()
  - Add a weak generic pci_domain_nr() that returns bridge.domain_nr
  - Add a way to create a host bridge in a specified domain, so we can
initialize bridge.domain_nr without using pci_domain_nr()
  - Convert each arch to use the new creation mechanism and drop its
pci_domain_nr() implementation

>  {
>   int error;
>   struct pci_host_bridge *bridge;
> @@ -1762,27 +1763,31 @@ struct pci_bus *pci_create_root_bus(struct device 
> *parent, int bus,
>  
>   bridge = pci_alloc_host_bridge();
>   if (!bridge)
> - return NULL;
> + return ERR_PTR(-ENOMEM);
>  
>   bridge->dev.parent = parent;
>   bridge->dev.release = pci_release_host_bridge_dev;
> + bridge->domain_nr = domain;
>  
>   b = pci_alloc_bus();
> - if (!b)
> + if (!b) {
> + error = -ENOMEM;
>   goto err_out;
> + }
>  
>   b->sysdata = sysdata;
>   b->ops = ops;
>   b->number = b->busn_res.start = bus;
> - b2 = pci_find_bus(pci_domain_nr(b), bus);
> + b2 = pci_find_bus(bridge->domain_nr, bus);
>   if (b2) {
>   /* If we already got to this bus through a different bridge, 
> ignore it */
>   dev_dbg(&b2->dev, "bus already known\n");
> + error = -EEXIST;
>   goto err_bus_out;
>   }
>  
>   bridge->bus = b;
> - dev_set_name(&bridge->dev, "pci%04x:%02x", pci_domain_nr(b), bus);
> + dev_set_name(&bridge->dev, "pci%04x:%02x", bridge->domain_nr, bus);
>   error = pcibios_root_bridge_prepare(bridge);
>   if (error)
>   goto err_out;
> @@ -1801,7 +1806,7 @@ struct pci_bus *pci_create_root_bus(struct device 
> *parent, int bus,
>  
>   b->dev.class = &pcibus_class;
>   b->dev.parent = b->bridge;
> - dev_set_name(&b->dev, "%04x:%02x", pci_domain_nr(b), bus);
> + dev_set_name(&b->dev, "%04x:%02x", bridge->domain_nr, bus);
>   error = device_register(&b->dev);
>   if (error)
>   goto class_dev_reg_err;
> @@ -1851,7 +1856,27 @@ err_bus_out:
>   kfree(b);
>  err_out:
>   kfree(bridge);
> - return NULL;
> + return ERR_PTR(error);
> +}
> +
> +struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
> + struct pci_ops *ops, void *sysdata, struct list_head *resources)
> +{
> + int domain_nr;
> + struct pci_bus *b = pci_alloc_bus();
> + if (!b)
> + return NULL;
> +
> + b->sysdata = sysdata;
> + domain_nr = pci_domain_nr(b);
> + kfree(b);
> +
> + b = pci_create_root_bus_in_domain(parent, domain_nr, bus,
> + ops, sysdata, resources);
> + if (IS_ERR(b))
> + return NULL;
> +
> + return b;
>  }
>  
>  int pci_bus_insert_busn_res(struct pci_bus *b, int bus, int bus_max)
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 466bcd1..7e7b939 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -401,6 +401,7 @@ struct pci_host_bridge_window {
>  struct pci_host_bridge {
>   struct de

Re: [PATCHv2 1/3] of: Split early_init_dt_scan into two parts

[Laura Abbott]

On 7/1/2014 7:03 PM, Laura Abbott wrote:
> Currently, early_init_dt_scan validates the header, sets the
> boot params, and scans for chosen/memory all in one function.
> Split this up into two separate functions (validation/setting
> boot params in one, scanning in another) to allow for
> additional setup between boot params and scanning the memory.
> 
> Signed-off-by: Laura Abbott 

I haven't heard anything more on this series but the holiday weekend
in the US probably affected that.

Grant/Rob are you okay with taking this through the devicetree tree 
if this gets a few more acks or would you rather this go through
an ARM tree?

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] of: Use proper types for checking memory overflow

[Laura Abbott]

Commit a67a6ed15513541579d38bcbd127e7be170710e5
(of: Check for phys_addr_t overflows in early_init_dt_add_memory_arch)
corrected early_init_dt_add_memory_arch to account for overflows
but did so in an unclean way using ULONG_MAX. There is no
guarantee that sizeof(unsigned long) == sizeof(phys_addr_t).
Check against phys_addr_t instead.

Signed-off-by: Laura Abbott 
---
 drivers/of/fdt.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index b777d8f..b88a68e 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -875,24 +875,24 @@ int __init early_init_dt_scan_chosen(unsigned long node, 
const char *uname,
 }
 
 #ifdef CONFIG_HAVE_MEMBLOCK
+#define MAX_PHYS_ADDR  ((phys_addr_t)~0)
+
 void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
 {
const u64 phys_offset = __pa(PAGE_OFFSET);
base &= PAGE_MASK;
size &= PAGE_MASK;
 
-   if (sizeof(phys_addr_t) < sizeof(u64)) {
-   if (base > ULONG_MAX) {
-   pr_warning("Ignoring memory block 0x%llx - 0x%llx\n",
-   base, base + size);
-   return;
-   }
+   if (base > MAX_PHYS_ADDR) {
+   pr_warning("Ignoring memory block 0x%llx - 0x%llx\n",
+   base, base + size);
+   return;
+   }
 
-   if (base + size > ULONG_MAX) {
-   pr_warning("Ignoring memory range 0x%lx - 0x%llx\n",
-   ULONG_MAX, base + size);
-   size = ULONG_MAX - base;
-   }
+   if (base + size > MAX_PHYS_ADDR) {
+   pr_warning("Ignoring memory range 0x%lx - 0x%llx\n",
+   ULONG_MAX, base + size);
+   size = MAX_PHYS_ADDR - base;
}
 
if (base + size < phys_offset) {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 06/14] drm/exynos: fimd: support LCD I80 interface

[YoungJun Cho]

To support MIPI command mode based I80 interface panel,
FIMD should do followings:
- Sets LCD I80 interface timings configuration.
- Uses "lcd_sys" as an IRQ resource and sets relevant IRQ configuration.
- Sets LCD block configuration for I80 interface.
- Sets ideal(pixel) clock is 2 times faster than the original one
  to generate frame done IRQ prior to the next TE signal.
- Implements trigger feature that transfers image data if there is page
  flip request, and implements TE handler to call trigger function.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/Kconfig   |   1 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 276 ++-
 include/video/samsung_fimd.h |   3 +-
 3 files changed, 235 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 178d2a9..9ba1aae 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -28,6 +28,7 @@ config DRM_EXYNOS_FIMD
bool "Exynos DRM FIMD"
depends on DRM_EXYNOS && !FB_S3C
select FB_MODE_HELPERS
+   select MFD_SYSCON
help
  Choose this option if you want to use Exynos FIMD for DRM.
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 33161ad..207872d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -61,6 +63,24 @@
 /* color key value register for hardware window 1 ~ 4. */
 #define WKEYCON1_BASE(x)   ((WKEYCON1 + 0x140) + ((x - 1) * 8))
 
+/* I80 / RGB trigger control register */
+#define TRIGCON0x1A4
+#define TRGMODE_I80_RGB_ENABLE_I80 (1 << 0)
+#define SWTRGCMD_I80_RGB_ENABLE(1 << 1)
+
+/* display mode change control register except exynos4 */
+#define VIDOUT_CON 0x000
+#define VIDOUT_CON_F_I80_LDI0  (0x2 << 8)
+
+/* I80 interface control for main LDI register */
+#define I80IFCONFAx(x) (0x1B0 + (x) * 4)
+#define I80IFCONFBx(x) (0x1B8 + (x) * 4)
+#define LCD_CS_SETUP(x)((x) << 16)
+#define LCD_WR_SETUP(x)((x) << 12)
+#define LCD_WR_ACTIVE(x)   ((x) << 8)
+#define LCD_WR_HOLD(x) ((x) << 4)
+#define I80IFEN_ENABLE (1 << 0)
+
 /* FIMD has totally five hardware windows. */
 #define WINDOWS_NR 5
 
@@ -68,10 +88,14 @@
 
 struct fimd_driver_data {
unsigned int timing_base;
+   unsigned int lcdblk_offset;
+   unsigned int lcdblk_vt_shift;
+   unsigned int lcdblk_bypass_shift;
 
unsigned int has_shadowcon:1;
unsigned int has_clksel:1;
unsigned int has_limited_fmt:1;
+   unsigned int has_vidoutcon:1;
 };
 
 static struct fimd_driver_data s3c64xx_fimd_driver_data = {
@@ -82,12 +106,19 @@ static struct fimd_driver_data s3c64xx_fimd_driver_data = {
 
 static struct fimd_driver_data exynos4_fimd_driver_data = {
.timing_base = 0x0,
+   .lcdblk_offset = 0x210,
+   .lcdblk_vt_shift = 10,
+   .lcdblk_bypass_shift = 1,
.has_shadowcon = 1,
 };
 
 static struct fimd_driver_data exynos5_fimd_driver_data = {
.timing_base = 0x2,
+   .lcdblk_offset = 0x214,
+   .lcdblk_vt_shift = 24,
+   .lcdblk_bypass_shift = 15,
.has_shadowcon = 1,
+   .has_vidoutcon = 1,
 };
 
 struct fimd_win_data {
@@ -112,15 +143,22 @@ struct fimd_context {
struct clk  *bus_clk;
struct clk  *lcd_clk;
void __iomem*regs;
+   struct regmap   *sysreg;
struct drm_display_mode mode;
struct fimd_win_datawin_data[WINDOWS_NR];
unsigned intdefault_win;
unsigned long   irq_flags;
+   u32 vidcon0;
u32 vidcon1;
+   u32 vidout_con;
+   u32 i80ifcon;
+   booli80_if;
boolsuspended;
int pipe;
wait_queue_head_t   wait_vsync_queue;
atomic_twait_vsync_event;
+   atomic_twin_updated;
+   atomic_ttriggering;
 
struct exynos_drm_panel_info panel;
struct fimd_driver_data *driver_data;
@@ -243,6 +281,14 @@ static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
unsigned long ideal_clk = mode->htotal * mode->vtotal * mode->vrefresh;
u32 clkdiv;
 
+   if (ctx->i80_if) {
+   /*
+* The frame done interrupt sho

[PATCH v5 05/14] drm/exynos: dsi: add pass TE host ops to support LCD I80 interface

[YoungJun Cho]

To support LCD I80 interface, the DSI host calls this function
to notify the panel tearing effect synchronization signal to
the CRTC device manager to trigger to transfer video image.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 11 +++
 include/drm/drm_mipi_dsi.h  |  7 +++
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index dad543a..76e34ca 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 
+#include "exynos_drm_crtc.h"
 #include "exynos_drm_drv.h"
 
 /* returns true iff both arguments logically differs */
@@ -1041,10 +1042,20 @@ static ssize_t exynos_dsi_host_transfer(struct 
mipi_dsi_host *host,
return (ret < 0) ? ret : xfer.rx_done;
 }
 
+static void exynos_dsi_host_pass_te(struct mipi_dsi_host *host)
+{
+   struct exynos_dsi *dsi = host_to_dsi(host);
+   struct drm_encoder *encoder = dsi->encoder;
+
+   if (dsi->state & DSIM_STATE_ENABLED)
+   exynos_drm_crtc_te_handler(encoder->crtc);
+}
+
 static const struct mipi_dsi_host_ops exynos_dsi_ops = {
.attach = exynos_dsi_host_attach,
.detach = exynos_dsi_host_detach,
.transfer = exynos_dsi_host_transfer,
+   .pass_te = exynos_dsi_host_pass_te,
 };
 
 static int exynos_dsi_poweron(struct exynos_dsi *dsi)
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 944f33f..3f21bea 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -49,6 +49,12 @@ struct mipi_dsi_msg {
  * @detach: detach DSI device from DSI host
  * @transfer: send and/or receive DSI packet, return number of received bytes,
  *   or error
+ * @pass_te: call the crtc te_handler() callback from DSI host.
+ *  The panel generates tearing effect synchronization signal between
+ *  MCU and FB to display video images. And the display controller
+ *  should trigger to transfer video image at this signal. So the panel
+ *  receives the TE IRQ, then calls this function to notify it to the
+ *  display controller.
  */
 struct mipi_dsi_host_ops {
int (*attach)(struct mipi_dsi_host *host,
@@ -57,6 +63,7 @@ struct mipi_dsi_host_ops {
  struct mipi_dsi_device *dsi);
ssize_t (*transfer)(struct mipi_dsi_host *host,
struct mipi_dsi_msg *msg);
+   void (*pass_te)(struct mipi_dsi_host *host);
 };
 
 /**
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 14/14] ARM: dts: exynos5420: add dsi node

[YoungJun Cho]

This patch adds common part of dsi node.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 arch/arm/boot/dts/exynos5420.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 0b9d15d..3a7862b 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -523,6 +523,20 @@
#phy-cells = <1>;
};
 
+   dsi@1450 {
+   compatible = "samsung,exynos5410-mipi-dsi";
+   reg = <0x1450 0x1>;
+   interrupts = <0 82 0>;
+   samsung,power-domain = <&disp_pd>;
+   phys = <&mipi_phy 1>;
+   phy-names = "dsim";
+   clocks = <&clock CLK_DSIM1>, <&clock CLK_SCLK_MIPI1>;
+   clock-names = "bus_clk", "pll_clk";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
fimd: fimd@1440 {
samsung,power-domain = <&disp_pd>;
clocks = <&clock CLK_SCLK_FIMD1>, <&clock CLK_FIMD1>;
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 12/14] ARM: dts: exynos5: add system register property

[YoungJun Cho]

This patch adds sysreg property to fimd device node
which is required to use I80 interface.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 arch/arm/boot/dts/exynos5.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 79d0608..fdead12 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -87,6 +87,7 @@
reg = <0x1440 0x4>;
interrupt-names = "fifo", "vsync", "lcd_sys";
interrupts = <18 4>, <18 5>, <18 6>;
+   samsung,sysreg = <&sysreg_system_controller>;
status = "disabled";
};
 
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 10/14] drm/panel: add S6E3FA0 driver

[YoungJun Cho]

This patch adds MIPI DSI command mode based
S6E3FA0 AMOLED LCD Panel driver.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 drivers/gpu/drm/panel/Kconfig |   7 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-s6e3fa0.c | 569 ++
 3 files changed, 577 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 4ec874d..be1392e 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -30,4 +30,11 @@ config DRM_PANEL_S6E8AA0
select DRM_MIPI_DSI
select VIDEOMODE_HELPERS
 
+config DRM_PANEL_S6E3FA0
+   tristate "S6E3FA0 DSI command mode panel"
+   depends on DRM && DRM_PANEL
+   depends on OF
+   select DRM_MIPI_DSI
+   select VIDEOMODE_HELPERS
+
 endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 8b92921..85c6738 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
 obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
+obj-$(CONFIG_DRM_PANEL_S6E3FA0) += panel-s6e3fa0.o
diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c 
b/drivers/gpu/drm/panel/panel-s6e3fa0.c
new file mode 100644
index 000..66058a7
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
@@ -0,0 +1,569 @@
+/*
+ * MIPI DSI command mode based s6e3fa0 AMOLED LCD 5.7 inch drm panel driver.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * YoungJun Cho 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/* Manufacturer Command Set */
+#define MCS_GLOBAL_PARAMETER   0xb0
+#define MCS_AID0xb2
+#define MCS_ELVSSOPT   0xb6
+#define MCS_TEMPERATURE_SET0xb8
+#define MCS_PENTILE_CTRL   0xc0
+#define MCS_GAMMA_MODE 0xca
+#define MCS_VDDM   0xd7
+#define MCS_ALS0xe3
+#define MCS_ERR_FG 0xed
+#define MCS_KEY_LEV1   0xf0
+#define MCS_GAMMA_UPDATE   0xf7
+#define MCS_KEY_LEV2   0xfc
+#define MCS_RE 0xfe
+#define MCS_TOUT2_HSYNC0xff
+
+/* Content Adaptive Brightness Control */
+#define DCS_WRITE_CABC 0x55
+
+#define MTP_ID_LEN 3
+#define GAMMA_LEVEL_NUM30
+
+#define DEFAULT_VDDM_VAL   0x15
+
+struct s6e3fa0 {
+   struct device   *dev;
+   struct drm_panelpanel;
+
+   struct regulator_bulk_data  supplies[2];
+   struct gpio_desc*reset_gpio;
+   struct gpio_desc*det_gpio;
+   struct gpio_desc*te_gpio;
+   struct videomodevm;
+
+   unsigned intpower_on_delay;
+   unsigned intreset_delay;
+   unsigned intinit_delay;
+   unsigned intwidth_mm;
+   unsigned intheight_mm;
+
+   unsigned char   id;
+   unsigned char   vddm;
+   unsigned intbrightness;
+};
+
+#define panel_to_s6e3fa0(p) container_of(p, struct s6e3fa0, panel)
+
+/* VDD Memory Lookup Table contains pairs of {ReadValue, WriteValue} */
+static const unsigned char s6e3fa0_vddm_lut[][2] = {
+   {0x00, 0x0d}, {0x01, 0x0d}, {0x02, 0x0e}, {0x03, 0x0f}, {0x04, 0x10},
+   {0x05, 0x11}, {0x06, 0x12}, {0x07, 0x13}, {0x08, 0x14}, {0x09, 0x15},
+   {0x0a, 0x16}, {0x0b, 0x17}, {0x0c, 0x18}, {0x0d, 0x19}, {0x0e, 0x1a},
+   {0x0f, 0x1b}, {0x10, 0x1c}, {0x11, 0x1d}, {0x12, 0x1e}, {0x13, 0x1f},
+   {0x14, 0x20}, {0x15, 0x21}, {0x16, 0x22}, {0x17, 0x23}, {0x18, 0x24},
+   {0x19, 0x25}, {0x1a, 0x26}, {0x1b, 0x27}, {0x1c, 0x28}, {0x1d, 0x29},
+   {0x1e, 0x2a}, {0x1f, 0x2b}, {0x20, 0x2c}, {0x21, 0x2d}, {0x22, 0x2e},
+   {0x23, 0x2f}, {0x24, 0x30}, {0x25, 0x31}, {0x26, 0x32}, {0x27, 0x33},
+   {0x28, 0x34}, {0x29, 0x35}, {0x2a, 0x36}, {0x2b, 0x37}, {0x2c, 0x38},
+   {0x2d, 0x39}, {0x2e, 0x3a}, {0x2f, 0x3b}, {0x30, 0x3c}, {0x31, 0x3d},
+   {0x32, 0x3e}, {0x33, 0x3f}, {0x34, 0x3f}, {0x35, 0x3f}, {0x36, 0x3f},
+   {0x37, 0x3f}, {0x38, 0x3f}, {0x39, 0x3f}, {0x3a, 0x3f}, {0x3b, 0x3f},
+   {0x3c, 0x3f}, {0x3d, 0x3f}, {0x3e, 0x3f}, {0x3f, 0x3f}, {0x40, 0x0c},
+   {0x41, 0x0b}, {0x42, 0x0a}, {0x43, 0x09}, {0x44, 0x08}, {0x45, 0x07},
+   {0x46, 0x06}, {0x47, 0x05}, {0x48, 0x04}, {0x

[PATCH v5 13/14] ARM: dts: exynos5420: add mipi-phy node

[YoungJun Cho]

This patch adds mipi-phy node for MIPI DSI device.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 arch/arm/boot/dts/exynos5420.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index e385322..0b9d15d 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -517,6 +517,12 @@
phy-names = "dp";
};
 
+   mipi_phy: video-phy@10040714 {
+   compatible = "samsung,s5pv210-mipi-video-phy";
+   reg = <0x10040714 12>;
+   #phy-cells = <1>;
+   };
+
fimd: fimd@1440 {
samsung,power-domain = <&disp_pd>;
clocks = <&clock CLK_SCLK_FIMD1>, <&clock CLK_FIMD1>;
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 08/14] drm/exynos: dsi: add driver data to support Exynos5410/5420/5440 SoCs

[YoungJun Cho]

The offset of register DSIM_PLLTMR_REG in Exynos5410 / 5420 / 5440
SoCs is different from the one in Exynos4 SoCs.

In case of Exynos5410 / 5420 / 5440 SoCs, there is no frequency
band bit in DSIM_PLLCTRL_REG, and it uses DSIM_PHYCTRL_REG and
DSIM_PHYTIMING*_REG instead.
So this patch adds driver data to distinguish it.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 157 +++-
 1 file changed, 135 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 76e34ca..162f74d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -55,9 +56,12 @@
 
 /* FIFO memory AC characteristic register */
 #define DSIM_PLLCTRL_REG   0x4c/* PLL control register */
-#define DSIM_PLLTMR_REG0x50/* PLL timer register */
 #define DSIM_PHYACCHR_REG  0x54/* D-PHY AC characteristic register */
 #define DSIM_PHYACCHR1_REG 0x58/* D-PHY AC characteristic register1 */
+#define DSIM_PHYCTRL_REG   0x5c
+#define DSIM_PHYTIMING_REG 0x64
+#define DSIM_PHYTIMING1_REG0x68
+#define DSIM_PHYTIMING2_REG0x6c
 
 /* DSIM_STATUS */
 #define DSIM_STOP_STATE_DAT(x) (((x) & 0xf) << 0)
@@ -201,6 +205,24 @@
 #define DSIM_PLL_M(x)  ((x) << 4)
 #define DSIM_PLL_S(x)  ((x) << 1)
 
+/* DSIM_PHYCTRL */
+#define DSIM_PHYCTRL_ULPS_EXIT(x)  (((x) & 0x1ff) << 0)
+
+/* DSIM_PHYTIMING */
+#define DSIM_PHYTIMING_LPX(x)  ((x) << 8)
+#define DSIM_PHYTIMING_HS_EXIT(x)  ((x) << 0)
+
+/* DSIM_PHYTIMING1 */
+#define DSIM_PHYTIMING1_CLK_PREPARE(x) ((x) << 24)
+#define DSIM_PHYTIMING1_CLK_ZERO(x)((x) << 16)
+#define DSIM_PHYTIMING1_CLK_POST(x)((x) << 8)
+#define DSIM_PHYTIMING1_CLK_TRAIL(x)   ((x) << 0)
+
+/* DSIM_PHYTIMING2 */
+#define DSIM_PHYTIMING2_HS_PREPARE(x)  ((x) << 16)
+#define DSIM_PHYTIMING2_HS_ZERO(x) ((x) << 8)
+#define DSIM_PHYTIMING2_HS_TRAIL(x)((x) << 0)
+
 #define DSI_MAX_BUS_WIDTH  4
 #define DSI_NUM_VIRTUAL_CHANNELS   4
 #define DSI_TX_FIFO_SIZE   2048
@@ -234,6 +256,12 @@ struct exynos_dsi_transfer {
 #define DSIM_STATE_INITIALIZED BIT(1)
 #define DSIM_STATE_CMD_LPM BIT(2)
 
+struct exynos_dsi_driver_data {
+   unsigned int plltmr_reg;
+
+   unsigned int has_freqband:1;
+};
+
 struct exynos_dsi {
struct mipi_dsi_host dsi_host;
struct drm_connector connector;
@@ -263,11 +291,39 @@ struct exynos_dsi {
 
spinlock_t transfer_lock; /* protects transfer_list */
struct list_head transfer_list;
+
+   struct exynos_dsi_driver_data *driver_data;
 };
 
 #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
 #define connector_to_dsi(c) container_of(c, struct exynos_dsi, connector)
 
+static struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
+   .plltmr_reg = 0x50,
+   .has_freqband = 1,
+};
+
+static struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
+   .plltmr_reg = 0x58,
+};
+
+static struct of_device_id exynos_dsi_of_match[] = {
+   { .compatible = "samsung,exynos4210-mipi-dsi",
+ .data = &exynos4_dsi_driver_data },
+   { .compatible = "samsung,exynos5410-mipi-dsi",
+ .data = &exynos5_dsi_driver_data },
+   { }
+};
+
+static inline struct exynos_dsi_driver_data *exynos_dsi_get_driver_data(
+   struct platform_device *pdev)
+{
+   const struct of_device_id *of_id =
+   of_match_device(exynos_dsi_of_match, &pdev->dev);
+
+   return (struct exynos_dsi_driver_data *)of_id->data;
+}
+
 static void exynos_dsi_wait_for_reset(struct exynos_dsi *dsi)
 {
if (wait_for_completion_timeout(&dsi->completed, msecs_to_jiffies(300)))
@@ -341,14 +397,9 @@ static unsigned long exynos_dsi_pll_find_pms(struct 
exynos_dsi *dsi,
 static unsigned long exynos_dsi_set_pll(struct exynos_dsi *dsi,
unsigned long freq)
 {
-   static const unsigned long freq_bands[] = {
-   100 * MHZ, 120 * MHZ, 160 * MHZ, 200 * MHZ,
-   270 * MHZ, 320 * MHZ, 390 * MHZ, 450 * MHZ,
-   510 * MHZ, 560 * MHZ, 640 * MHZ, 690 * MHZ,
-   770 * MHZ, 870 * MHZ, 950 * MHZ,
-   };
+   struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
unsigned long fin, fout;
-   int timeout, band;
+   int timeout;
u8 p, s;
u16 m;
u32 reg;
@@ -369,18 +420,30 @@ static unsigned long exynos_dsi_set_pll(struct exynos_dsi 
*dsi,
"failed to find PLL PMS for requested frequency\n");
return -EFAULT;
}
+   dev_dbg(dsi->dev, "PLL freq %lu, (p %d, m %d, s %d)\n", fout, p,

[PATCH v5 03/14] ARM: dts: samsung-fimd: add LCD I80 interface specific properties

[YoungJun Cho]

In case of using MIPI DSI based I80 interface panel,
the relevant registers should be set.
So this patch adds relevant DT bindings.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 .../devicetree/bindings/video/samsung-fimd.txt | 28 ++
 1 file changed, 28 insertions(+)

diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt 
b/Documentation/devicetree/bindings/video/samsung-fimd.txt
index 2dad41b..59ff61e 100644
--- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
+++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
@@ -44,6 +44,34 @@ Optional Properties:
 - display-timings: timing settings for FIMD, as described in document [1].
Can be used in case timings cannot be provided otherwise
or to override timings provided by the panel.
+- samsung,sysreg: handle to syscon used to control the system registers
+- i80-if-timings: timing configuration for lcd i80 interface support.
+  - cs-setup: clock cycles for the active period of address signal is enabled
+  until chip select is enabled.
+  If not specified, the default value(0) will be used.
+  - wr-setup: clock cycles for the active period of CS signal is enabled until
+  write signal is enabled.
+  If not specified, the default value(0) will be used.
+  - wr-active: clock cycles for the active period of CS is enabled.
+   If not specified, the default value(1) will be used.
+  - wr-hold: clock cycles for the active period of CS is disabled until write
+ signal is disabled.
+ If not specified, the default value(0) will be used.
+
+  The parameters are defined as:
+
+VCLK(internal)  __|¯¯|_|¯¯|_|¯¯|_|¯¯|_|¯¯
+  :::::
+Address Output  --:|:::
+Chip Select ¯¯¯|::|¯¯
+   | wr-setup+1 || wr-hold+1  |
+   |<-->||<-->|
+Write Enable||¯¯¯
+| wr-active+1|
+|<-->|
+Video Data  --
 
 The device node can contain 'port' child nodes according to the bindings 
defined
 in [2]. The following are properties specific to those nodes:
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 09/14] ARM: dts: s6e3fa0: add DT bindings

[YoungJun Cho]

This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources and display timings.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 .../devicetree/bindings/panel/samsung,s6e3fa0.txt  | 46 ++
 1 file changed, 46 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt

diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt 
b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
new file mode 100644
index 000..2cd32f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
@@ -0,0 +1,46 @@
+Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
+
+Required properties:
+  - compatible: "samsung,s6e3fa0"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: core voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin
+  - det-gpios: a GPIO spec for the OLED detection pin
+  - te-gpios: a GPIO spec for the TE pin
+  - display-timings: timings for the connected panel as described by [1]
+
+Optional properties:
+
+The device node can contain one 'port' child node with one child 'endpoint'
+node, according to the bindings defined in [2]. This node should describe
+panel's video bus.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+   panel@0 {
+   compatible = "samsung,s6e3fa0";
+   reg = <0>;
+   vdd3-supply = <&vcclcd_reg>;
+   vci-supply = <&vlcd_reg>;
+   reset-gpios = <&gpy7 4 0>;
+   det-gpios = <&gpg0 6 0>;
+   te-gpios = <&gpd1 7 0>;
+
+   display-timings {
+   timings0 {
+   clock-frequency = <0>;
+   hactive = <1080>;
+   vactive = <1920>;
+   hfront-porch = <2>;
+   hback-porch = <2>;
+   hsync-len = <1>;
+   vfront-porch = <1>;
+   vback-porch = <4>;
+   vsync-len = <1>;
+   };
+   };
+   };
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 01/14] drm/exynos: dsi: move the EoT packets configuration point

[YoungJun Cho]

This configuration could be used in MIPI DSI command mode also.
And adds user manual description for display configuration.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 6302aa6..dad543a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -468,13 +468,19 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
/* DSI configuration */
reg = 0;
 
+   /* The first bit of mode_flags specifies display configuration.
+* If this bit is set[= MIPI_DSI_MODE_VIDEO], dsi will support video
+* mode, otherwise it will support command mode.
+*/
if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
reg |= DSIM_VIDEO_MODE;
 
+   /*
+* The user manual describes that following bits are ignored in
+* command mode.
+*/
if (!(dsi->mode_flags & MIPI_DSI_MODE_VSYNC_FLUSH))
reg |= DSIM_MFLUSH_VS;
-   if (!(dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET))
-   reg |= DSIM_EOT_DISABLE;
if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
reg |= DSIM_SYNC_INFORM;
if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
@@ -491,6 +497,9 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
reg |= DSIM_HSA_MODE;
}
 
+   if (!(dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET))
+   reg |= DSIM_EOT_DISABLE;
+
switch (dsi->format) {
case MIPI_DSI_FMT_RGB888:
reg |= DSIM_MAIN_PIX_FORMAT_RGB888;
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 11/14] ARM: dts: exynos4: add system register property

[YoungJun Cho]

This patch adds sysreg property to fimd device node
which is required to use I80 interface.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 arch/arm/boot/dts/exynos4.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index b8ece4b..92ee786 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -608,6 +608,7 @@
clocks = <&clock CLK_SCLK_FIMD0>, <&clock CLK_FIMD0>;
clock-names = "sclk_fimd", "fimd";
samsung,power-domain = <&pd_lcd0>;
+   samsung,sysreg = <&sys_reg>;
status = "disabled";
};
 };
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 04/14] drm/exynos: add TE handler to support LCD I80 interface

[YoungJun Cho]

To support LCD I80 interface, the panel should generate
Tearing Effect synchronization signal between MCU and FB
to display video images.
And the display controller should trigger to transfer
video image at this signal.
So the panel receives the TE IRQ, then calls these handler
chains to notify it to the display controller.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 8 
 drivers/gpu/drm/exynos/exynos_drm_crtc.h | 7 +++
 drivers/gpu/drm/exynos/exynos_drm_drv.h  | 3 +++
 3 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 3bf091d..b68e58f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -511,3 +511,11 @@ int exynos_drm_crtc_get_pipe_from_type(struct drm_device 
*drm_dev,
 
return -EPERM;
 }
+
+void exynos_drm_crtc_te_handler(struct drm_crtc *crtc)
+{
+   struct exynos_drm_manager *manager = to_exynos_crtc(crtc)->manager;
+
+   if (manager->ops->te_handler)
+   manager->ops->te_handler(manager);
+}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index 9f74b10..690dcdd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -36,4 +36,11 @@ void exynos_drm_crtc_plane_disable(struct drm_crtc *crtc, 
int zpos);
 int exynos_drm_crtc_get_pipe_from_type(struct drm_device *drm_dev,
unsigned int out_type);
 
+/*
+ * This function calls the crtc device(manager)'s te_handler() callback
+ * to trigger to transfer video image at the tearing effect synchronization
+ * signal.
+ */
+void exynos_drm_crtc_te_handler(struct drm_crtc *crtc);
+
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 06cde45..d4e0726 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -188,6 +188,8 @@ struct exynos_drm_display {
  * @win_commit: apply hardware specific overlay data to registers.
  * @win_enable: enable hardware specific overlay.
  * @win_disable: disable hardware specific overlay.
+ * @te_handler: trigger to transfer video image at the tearing effect
+ * synchronization signal if there is a page flip request.
  */
 struct exynos_drm_manager;
 struct exynos_drm_manager_ops {
@@ -206,6 +208,7 @@ struct exynos_drm_manager_ops {
void (*win_commit)(struct exynos_drm_manager *mgr, int zpos);
void (*win_enable)(struct exynos_drm_manager *mgr, int zpos);
void (*win_disable)(struct exynos_drm_manager *mgr, int zpos);
+   void (*te_handler)(struct exynos_drm_manager *mgr);
 };
 
 /*
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 00/14] drm/exynos: support LCD I80 interface display

[YoungJun Cho]

Hi,

This series adds LCD I80 interface display support for Exynos DRM driver.
The FIMD(display controller) specification describes it as "LCD I80 interface"
and the DSI specification describes it as "Command mode interface".

This is based on exynos-drm-next branch.

The previous patches,
RFC: http://www.spinics.net/lists/dri-devel/msg58898.html
V1: http://www.spinics.net/lists/dri-devel/msg59291.html
V2: http://www.spinics.net/lists/dri-devel/msg59867.html
V3: http://www.spinics.net/lists/dri-devel/msg60708.html
V4: http://www.spinics.net/lists/dri-devel/msg60943.html

Changelog v2:
- Fixes typo and removes unnecessary error log (commented by Andrzej Hazda)
- Adds missed pendlig_flip flag clear points (commented by Daniel Kurtz)

Changelog v3:
- Removes generic command mode and command mode display timing interface.
- Moves I80 interface timings from panel DT to the FIMD(display controller) DT.

Changelog v4:
- Removes exynos5 sysreg(syscon) DT bindings and node from dtsi because
  it was already updated by linux-samsung-soc (commented by Vivek Gautam)

Changelog v5:
- Fixes FIMD vidcon0 register relevant code
- Fixes panel gamma table, disable sequence
- Slitely updates for code cleanup

Patches 1 and 2 fix trivial bugs.

Patches 3, 4, 5 and 6 implement FIMD(display controller) I80 interface.
The MIPI DSI command mode based panel generates Tearing Effect synchronization
signal between MCU and FB to display video image, and FIMD should trigger to
transfer video image at this signal.
So the panel should receive the TE IRQ and call TE handler chains to notify
it to the FIMD.

Patches 7 and 8 implement to use Exynos5410 / 5420 / 5440 SoC DSI driver
which is different from previous Exynos4 SoCs for some registers control.

Patches 9 and 10 introduce MIPI DSI command mode based Samsung S6E3FA0 AMOLED
5.7" LCD drm panel driver.

The ohters add DT property nodes to support MIPI DSI command mode.

I welcome any comments.

Thank you.
Best regards YJ

YoungJun Cho (14):
  drm/exynos: dsi: move the EoT packets configuration point
  drm/exynos: use wait_event_timeout() for safety usage
  ARM: dts: samsung-fimd: add LCD I80 interface specific properties
  drm/exynos: add TE handler to support LCD I80 interface
  drm/exynos: dsi: add pass TE host ops to support LCD I80 interface
  drm/exynos: fimd: support LCD I80 interface
  ARM: dts: exynos_dsim: add exynos5410 compatible to DT bindings
  drm/exynos: dsi: add driver data to support Exynos5410/5420/5440 SoCs
  ARM: dts: s6e3fa0: add DT bindings
  drm/panel: add S6E3FA0 driver
  ARM: dts: exynos4: add system register property
  ARM: dts: exynos5: add system register property
  ARM: dts: exynos5420: add mipi-phy node
  ARM: dts: exynos5420: add dsi node

 .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |  46 ++
 .../devicetree/bindings/video/exynos_dsim.txt  |   4 +-
 .../devicetree/bindings/video/samsung-fimd.txt |  28 +
 arch/arm/boot/dts/exynos4.dtsi |   1 +
 arch/arm/boot/dts/exynos5.dtsi |   1 +
 arch/arm/boot/dts/exynos5420.dtsi  |  20 +
 drivers/gpu/drm/exynos/Kconfig |   1 +
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   |  15 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.h   |   7 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   3 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c| 181 ++-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 276 --
 drivers/gpu/drm/panel/Kconfig  |   7 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-s6e3fa0.c  | 569 +
 include/drm/drm_mipi_dsi.h |   7 +
 include/video/samsung_fimd.h   |   3 +-
 17 files changed, 1098 insertions(+), 72 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
 create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c

-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 02/14] drm/exynos: use wait_event_timeout() for safety usage

[YoungJun Cho]

There could be the case that the page flip operation isn't finished correctly
with some abnormal condition such as panel reset. So this patch replaces
wait_event() with wait_event_timeout() to avoid waiting for page flip completion
infinitely.
And clears exynos_crtc->pending_flip in exynos_drm_crtc_page_flip()
when exynos_drm_crtc_mode_set_commit() is failed.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 95c9435..3bf091d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -69,8 +69,10 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int 
mode)
 
if (mode > DRM_MODE_DPMS_ON) {
/* wait for the completion of page flip. */
-   wait_event(exynos_crtc->pending_flip_queue,
-   atomic_read(&exynos_crtc->pending_flip) == 0);
+   if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
+   !atomic_read(&exynos_crtc->pending_flip),
+   HZ/20))
+   atomic_set(&exynos_crtc->pending_flip, 0);
drm_vblank_off(crtc->dev, exynos_crtc->pipe);
}
 
@@ -259,6 +261,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
spin_lock_irq(&dev->event_lock);
drm_vblank_put(dev, exynos_crtc->pipe);
list_del(&event->base.link);
+   atomic_set(&exynos_crtc->pending_flip, 0);
spin_unlock_irq(&dev->event_lock);
 
goto out;
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 07/14] ARM: dts: exynos_dsim: add exynos5410 compatible to DT bindings

[YoungJun Cho]

This patch adds relevant to exynos5410 compatible
for exynos5410 / 5420 / 5440 SoCs support.

Signed-off-by: YoungJun Cho 
Acked-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 Documentation/devicetree/bindings/video/exynos_dsim.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt 
b/Documentation/devicetree/bindings/video/exynos_dsim.txt
index 33b5730..31036c6 100644
--- a/Documentation/devicetree/bindings/video/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
@@ -1,7 +1,9 @@
 Exynos MIPI DSI Master
 
 Required properties:
-  - compatible: "samsung,exynos4210-mipi-dsi"
+  - compatible: value should be one of the following
+   "samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */
+   "samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs 
*/
   - reg: physical base address and length of the registers set for the device
   - interrupts: should contain DSI interrupt
   - clocks: list of clock specifiers, must contain an entry for each required
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mtd: nand: stm_nand_bch: add new driver

[Brian Norris]

Hi Lee, Pekon,

A few additions/corrections to Pekon's comments.

On Thu, Jul 03, 2014 at 09:09:27AM +, Pekon Gupta wrote:
> >From: Brian Norris [mailto:computersforpe...@gmail.com]
> >On Wed, May 28, 2014 at 10:20:05AM +0100, Lee Jones wrote:
> >> diff --git a/arch/arm/boot/dts/stih41x-b2020.dtsi 
> >> b/arch/arm/boot/dts/stih41x-b2020.dtsi
> >> index bc5818d..7a6a6e8 100644
> >> --- a/arch/arm/boot/dts/stih41x-b2020.dtsi
> >> +++ b/arch/arm/boot/dts/stih41x-b2020.dtsi
> >> @@ -52,5 +52,45 @@
> >>pinctrl-0   = <&pinctrl_rgmii1>;
> >>};
> >>
> >> +  nandbch: nand-bch {
> >
> >Shouldn't this be named 'nand@', 'flash@', or similar?
> >
> >> +  compatible = "st,nand-bch";
> >> +  reg = <0xfe901000 0x1000>, <0xfef00800 0x0800>;
> >> +  reg-names = "nand_mem", "nand_dma";
> >> +  interrupts = <0 139 0x0>;
> >> +  interrupt-names = "nand_irq";
> >> +  st,nand-banks = <&nand_banks>;
> >> +  nand-ecc-strength = <0xFF>;
> 
> nit-pick to save yourself from another patch re-spin, Please use lower-case 
> hex :-)

Or in this case, drop the property altogether. I believe
nand-ecc-strength = 255 is a misuse of the binding, as Lee intended it
to mean "automatic". (It makes more sense to say that a missing
"nand-ecc-strength" property means Linux can 'automatically' choose.)

> >> +
> >> +  status = "okay";
> >> +  };
> >> +
...

> >> +static void bch_wait_seq(struct nandi_controller *nandi)
> >> +{
> >> +  int ret;
> >> +
> >> +  ret = wait_for_completion_timeout(&nandi->seq_completed, HZ/2);
> 
> Are you sure you want to use same timeout value for all operations
> like ERASE, READ, WRITE ? because
> (1) There is wide variance between:
> - BLOCK_ERASE:  max(tBER) = 10ms) for MT29F4G08 Micron NAND
> - PAGE_ERASE: max(tPROG) = 600usec for same Micron part.
> 
> (2) The value of HZ varies across kernel versions and hardware platforms.

Lee's use of HZ is correct. HZ represents one second, and it is useful
for giving an (approximate) timeout that is independent of timer tick
rate. It is equivalent to msecs_to_jiffies(1000), for example.

> I suggest you pass the timeout value in call to bch_wait_seq().
> And this timeout value should be like 2x of typical value of which you found
> during ONFI parsing, or from DT

I'm not sure it's very important to get a precise timeout value. It's
especially not worth a DT binding. Timeouts should be the exception, not
the rule, and should not be relied on (for example) for good performance.

> >> +  if (!ret)
> >> +  dev_err(nandi->dev, "BCH Seq timeout\n");
> >> +}
> >> +
...
> >> +  /* Load last page of block */
> >> +  offs = (loff_t)block << chip->phys_erase_shift;
> >> +  offs += mtd->erasesize - mtd->writesize;
> >> +  if (bch_read_page(nandi, offs, buf) < 0) {
> 
> *Important*: You shouldn't call internal functions directly here..
> Instead use chip->_read() OR mtd-read() that will:

Probably looking for mtd_read()?

> - keep this code independent of ECC modes added in your driver in future.
> - implicitly handle updating mtd->ecc_stat (like ecc_failed, bits_corrected).
> - implicitly take care of address alignments checks and offset calculations.
> 
>  >> +struct stm_plat_nand_bch_data {
> >> +  struct stm_nand_bank_data *bank;
> >> +  enum stm_nand_bch_ecc_config bch_ecc_cfg;
> >> +
> >> +  /* The threshold at which the number of corrected bit-flips per sector
> >> +   * is deemed to have reached an excessive level (triggers '-EUCLEAN' to
> >> +   * be returned to the caller).  The value should be in the range 1 to
> >> +   *  where  is 18 or 30, depending on the BCH
> >> +   * ECC mode in operation.  A value of 0 is interpreted by the driver as
> >> +   * .
> >> +   */
> >> +  unsigned int bch_bitflip_threshold;
> >
> >This field is never set or used...
> >
> >> +  bool flashss;
> >
> >Ditto.
> >
> Probably answered in [2]

OK, then mark it with a FIXME or TODO comment. Don't let every reader
come across this driver with the same questions.

> Please re-send the next version in similar squashed format, as its easy for 
> review.

Yes.

> And once Brian is okay, may be then you can re-send individual patches.

I don't see any need to send individual sub-patches for the driver (you
do, however, need to split out the DTS and Documentation/ portions as
separate patches). If you want to include the splitting, just link to a
git tree where patches can be found.

Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 3/9] pci: Introduce pci_register_io_range() helper function.

[Bjorn Helgaas]

On Tue, Jul 01, 2014 at 07:43:28PM +0100, Liviu Dudau wrote:
> Some architectures do not have a simple view of the PCI I/O space
> and instead use a range of CPU addresses that map to bus addresses. For
> some architectures these ranges will be expressed by OF bindings
> in a device tree file.
> 
> Introduce a pci_register_io_range() helper function with a generic
> implementation that can be used by such architectures to keep track
> of the I/O ranges described by the PCI bindings. If the PCI_IOBASE
> macro is not defined that signals lack of support for PCI and we
> return an error.
> 
> Signed-off-by: Liviu Dudau 
> ---
>  drivers/of/address.c   | 61 
> ++
>  include/linux/of_address.h |  1 +
>  2 files changed, 62 insertions(+)
> 
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 5edfcb0..1345733 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -5,6 +5,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  /* Max address size we deal with */
> @@ -601,12 +602,72 @@ const __be32 *of_get_address(struct device_node *dev, 
> int index, u64 *size,
>  }
>  EXPORT_SYMBOL(of_get_address);
>  
> +struct io_range {
> + struct list_head list;
> + phys_addr_t start;
> + resource_size_t size;
> +};
> +
> +static LIST_HEAD(io_range_list);
> +
> +/*
> + * Record the PCI IO range (expressed as CPU physical address + size).
> + * Return a negative value if an error has occured, zero otherwise
> + */
> +int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)

I don't understand the interface here.  What's the mapping from CPU
physical address to bus I/O port?  For example, I have the following
machine in mind:

  HWP0002:00: PCI Root Bridge (domain  [bus 00-1b])
  HWP0002:00: memory-mapped IO port space [mem 0xf801000-0xf801fff]
  HWP0002:00: host bridge window [io  0x-0x0fff]

  HWP0002:09: PCI Root Bridge (domain 0001 [bus 00-1b])
  HWP0002:09: memory-mapped IO port space [mem 0xf811000-0xf811fff]
  HWP0002:09: host bridge window [io  0x100-0x1000fff] (PCI address 
[0x0-0xfff])

The CPU physical memory [mem 0xf801000-0xf801fff] is translated by
the bridge to I/O ports 0x-0x0fff on PCI bus :00.  Drivers use,
e.g., "inb(0)" to access it.

Similarly, [mem 0xf811000-0xf811fff] is translated by the second
bridge to I/O ports 0x-0x0fff on PCI bus 0001:00.  Drivers use
"inb(0x100)" to access it.

pci_register_io_range() seems sort of like it's intended to track the
memory-mapped IO port spaces, e.g., [mem 0xf801000-0xf801fff].
But I would think you'd want to keep track of at least the base port
number on the PCI bus, too.  Or is that why it's weak?

Here's what these look like in /proc/iomem and /proc/ioports (note that
there are two resource structs for each memory-mapped IO port space: one
IORESOURCE_MEM for the memory-mapped area (used only by the host bridge
driver), and one IORESOURCE_IO for the I/O port space (this becomes the
parent of a region used by a regular device driver):

  /proc/iomem:
PCI Bus :00 I/O Ports -0fff
PCI Bus 0001:00 I/O Ports 0100-01000fff

  /proc/ioports:
-0fff : PCI Bus :00
0100-01000fff : PCI Bus 0001:00

> +{
> +#ifdef PCI_IOBASE
> + struct io_range *res;
> + resource_size_t allocated_size = 0;
> +
> + /* check if the range hasn't been previously recorded */
> + list_for_each_entry(res, &io_range_list, list) {
> + if (addr >= res->start && addr + size <= res->start + size)
> + return 0;
> + allocated_size += res->size;
> + }
> +
> + /* range not registed yet, check for available space */
> + if (allocated_size + size - 1 > IO_SPACE_LIMIT)
> + return -E2BIG;
> +
> + /* add the range to the list */
> + res = kzalloc(sizeof(*res), GFP_KERNEL);
> + if (!res)
> + return -ENOMEM;
> +
> + res->start = addr;
> + res->size = size;
> +
> + list_add_tail(&res->list, &io_range_list);
> +
> + return 0;
> +#else
> + return -EINVAL;
> +#endif
> +}
> +
>  unsigned long __weak pci_address_to_pio(phys_addr_t address)
>  {
> +#ifdef PCI_IOBASE
> + struct io_range *res;
> + resource_size_t offset = 0;
> +
> + list_for_each_entry(res, &io_range_list, list) {
> + if (address >= res->start &&
> + address < res->start + res->size) {
> + return res->start - address + offset;
> + }
> + offset += res->size;
> + }
> +
> + return (unsigned long)-1;
> +#else
>   if (address > IO_SPACE_LIMIT)
>   return (unsigned long)-1;
>  
>   return (unsigned long) address;
> +#endif
>  }
>  
>  static int __of_address_to_resource(struct device_node *dev,
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index c13b878

Re: [PATCH] mtd: nand: stm_nand_bch: add new driver

[Brian Norris]

Hi Boris,

On Thu, Jul 03, 2014 at 10:05:22AM +0200, Boris BREZILLON wrote:
> On Wed, 2 Jul 2014 17:22:37 -0700 Brian Norris  
> wrote:
> > On Wed, May 28, 2014 at 10:20:05AM +0100, Lee Jones wrote:
> > > +
> > > + nand_timing0: nand-timing {
> > > + sig-setup   = <10>;
> > > + sig-hold= <10>;
> > > + CE-deassert = <0>;
> > > + WE-to-RBn   = <100>;
> > > + wr-on   = <10>;
> > > + wr-off  = <30>;
> > > + rd-on   = <10>;
> > > + rd-off  = <30>;
> > > + chip-delay  = <30>; /* delay in us */
> > > + };
> > 
> > You didn't document any of this node. And I don't think we want to
> > specify every single timing parameter in DT; it may make sense to use
> > Boris Brezillon's approach (I note this further down, in the driver
> > code) for mapping non-ONFI NAND timings into a compatible ONFI timing
> > mode. This will greatly simplify the bindings needed, since it's
> > standardized and auto-detectable in many cases.
> 
> 
> AFAIR, the NAND timing representation for non-ONFI chips question was
> left unanswered:
> 
> https://lkml.org/lkml/2014/5/20/581
> 
> I can definitely respin my NAND timings series, but I'd like to be sure
> this is how you want it done before doing so.

Can we start by supporting ONFI-only (or ONFI-only, plus entries in
nand_flash_ids[]), and have nand_base provide the translation so drivers
can retrieve the info? Then we can begin supporting new drivers like
Lee's, and worry about the DT question separately.

BTW, Lee: you're completely missing the definitions for
'struct nand_sdr_timings' in this patch, so it doesn't compile.

> Just as a reminder, you and Jason thought NAND timings for non-ONFI
> chips could be auto detected thanks to READID informations (by storing
> some sort of "NANDID <-> timings" association table).

Yes, thanks for the reminder. I knew there was more than one reason I
was wary of Lee's patch (first, that it was duplication of another patch
set; and second, than I'm not sure it belongs in DT at all).

I think we should attempt to solve this without any need for DT
bindings, as most other parameters are auto-detectable in some sense
(even if we have to store some NANDID <-> timings tables). I think going
forward, we can expect that new NAND will use a JEDEC or ONFI spec, and
that we shouldn't have to scale nand_flash_ids[] to include too many
flash chip timings.

Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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/3] ARM: dts: Update the parent for Audss clocks in Exynos5420

[Kukjin Kim]

On 07/01/14 20:59, Tushar Behera wrote:

On 06/27/2014 08:18 PM, Kevin Hilman wrote:

On Fri, Jun 27, 2014 at 7:18 AM, Kevin Hilman  wrote:

On Thu, Jun 26, 2014 at 8:38 PM, Tushar Behera  wrote:


Would you please provide me the environment setting of your u-boot?
U-boot environment on my board has been over-written, I would like to
set it same as yours and try to reproduce the issue at my end. With only
'sound init', I don't seem to hit this issue anymore.


Attached is a full boot log using v3.16-rc2 with my patch adding
CLK_IGNORE_UNUSED to mau_epll and Doug's aclk66_peric patch.  In the
boot log, you'll see the output of 'printenv' inside u-boot where the
environment is dumped.


Oops, I sent you a boot log for the octa board.  Here's the one for
peach-pi with the same kernel (built with upstream exynos_defconfig)

Kevin



The u-boot version is a little different on my Peach-Pi as compared to
the market release version. Not sure if that is making any difference.

Peach # version

U-Boot 2013.04 (Feb 13 2014 - 16:35:03) for Peach
armv7a-cros-linux-gnueabi-gcc.real (4.8.1_cos_gg_feea904_4.8.1-r66)
4.8.x-google 20130905 (prerelease)
GNU ld (binutils-2.22_cos_gg_2) 2.22



Note that I've applied this only from this series so I'm not sure how 
much the problem can be solved...any updates for 1/3 and 3/3?


- Kukjin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 2/9] pci: Export find_pci_host_bridge() function.

[Bjorn Helgaas]

On Tue, Jul 01, 2014 at 07:43:27PM +0100, Liviu Dudau wrote:
> This is a useful function and we should make it visible outside the
> generic PCI code. Export it as a GPL symbol.
> 
> Signed-off-by: Liviu Dudau 
> Tested-by: Tanmay Inamdar 
> ---
>  drivers/pci/host-bridge.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c
> index 0e5f3c9..36c669e 100644
> --- a/drivers/pci/host-bridge.c
> +++ b/drivers/pci/host-bridge.c
> @@ -16,12 +16,13 @@ static struct pci_bus *find_pci_root_bus(struct pci_bus 
> *bus)
>   return bus;
>  }
>  
> -static struct pci_host_bridge *find_pci_host_bridge(struct pci_bus *bus)
> +struct pci_host_bridge *find_pci_host_bridge(struct pci_bus *bus)
>  {
>   struct pci_bus *root_bus = find_pci_root_bus(bus);
>  
>   return to_pci_host_bridge(root_bus->bridge);
>  }
> +EXPORT_SYMBOL_GPL(find_pci_host_bridge);

There's nothing in this series that uses find_pci_host_bridge(), so 
how about we just wait until we have something that needs it?

Also, if/when we export this, I'd prefer a name that starts with "pci_"
as most of the other interfaces do.

>  void pci_set_host_bridge_release(struct pci_host_bridge *bridge,
>void (*release_fn)(struct pci_host_bridge *),
> -- 
> 2.0.0
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 2/3] Documentation: gpio: Add APM X-Gene SoC GPIO controller DTS binding

[Anton Vorontsov]

On Mon, Jul 07, 2014 at 11:26:18PM +0200, Linus Walleij wrote:
...
> > There was another reason for this as well, part of the gpio code I read
> > was confusing me. So I look through the other gpio documentations and
> > found an example that did this as well.
> >
> > int of_gpio_simple_xlate(struct gpio_chip *gc,
> >  const struct of_phandle_args *gpiospec, u32 *flags)
> > {
> > /*
> >  * We're discouraging gpio_cells < 2, since that way you'll have to
> >  * write your own xlate function (that will have to retrive the GPIO
> >  * number and the flags from a single gpio cell -- this is possible,
> >  * but not recommended).
> >  */
> 
> Hm yeah that's right.
> 
> This check was added by Anton in 2008. Anton why did we discourage
> onecell GPIOs?

Yup, the check was there from the very beginning. Think of
OF_GPIO_ACTIVE_LOW flag (it is widely used in drivers.)

The documentation in Feng's driver says "second cell is used to specify
optional parameters (unused)," which is not entirely correct. With the
standard xlate call it is used for active-low flag. You can implement
active-low flag w/o using the second cell, but it will be ugly.

Thanks,

Anton
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/18] AT91: Call at91_register_devices in the board files

[Jean-Christophe PLAGNIOL-VILLARD]

On 16:52 Thu 03 Jul , Maxime Ripard wrote:
> Hi,
> 
> On Thu, Jul 03, 2014 at 10:29:58PM +0800, Jean-Christophe PLAGNIOL-VILLARD 
> wrote:
> > no do this at SoC level
> 
> Since it has to be done at init_machine, I don't see any other easy
> way to do this at the SoC level.
> 
> What is your suggestion?

do it earlier as there is not driver it will not change anything
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] devicetree/bindings/powerpc/fsl: Add binding for board

[Scott Wood]

On Mon, 2014-07-07 at 14:06 +0530, Priyanka Jain wrote:
> Signed-off-by: Priyanka Jain 
> ---
>  .../devicetree/bindings/powerpc/fsl/board.txt  |   17 -
>  1 files changed, 16 insertions(+), 1 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt 
> b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> index f35f295..7800729 100644
> --- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> @@ -1,8 +1,23 @@
>  Freescale Reference Board Bindings
>  
> -This document describes device tree bindings for various devices that
> +This document describes device tree bindings for board and  various devices 
> that
>  exist on some Freescale reference boards.
>  
> +* Board node
> +Required properties:
> +
> + - model : Should be "fsl,"
> + - compatible : Should be "fsl,"
> + example: "fsl,T1040RDB", "fsl,T1042RDB", "fsl,T1042RDB_PI"
> +  "fsl,T1040QDS", "fsl,T1042QDS"
> +
> +Example:
> +
> +/ {
> + model = "fsl,T1040RDB";
> + compatible = "fsl,T1040RDB";
> +};

We really don't need to do this for every board just to satisfy
checkpatch.

-Scott


--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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] devicetree/binding/powerpc/fsl: Add binding for CPLD

[Scott Wood]

On Fri, 2014-07-04 at 10:03 +0530, Priyanka Jain wrote:
> Some Freescale boards like T1040RDB have on board CPLD connected on
> the IFC bus. Add binding for this in board.txt file
> 
> Signed-off-by: Priyanka Jain 
> ---
> Changes for v2:
>  convert board name to lower-case based on Scott's suggestions
> 
>  .../devicetree/bindings/powerpc/fsl/board.txt  |   19 +++
>  1 files changed, 19 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt 
> b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> index 700dec4..f35f295 100644
> --- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> @@ -84,3 +84,22 @@ Example:
>   compatible = "fsl,bsc9132qds-fpga", "fsl,fpga-qixis-i2c";
>   reg = <0x66>;
>   };
> +
> +* Freescale on-board CPLD
> +
> +Some Freescale boards like T1040RDB have on board CPLD connected on
> +the IFC bus.
> +
> +Required properties:
> +- compatible: Should be a board-specific string like "fsl,-cpld"
> +  Example:
> + "fsl,t1040rdb-cpld", "fsl,t1042rdb-cpld", "fsl,t1042rdb_pi-cpld"
> +- reg: Should contain the chip select, address offset and length of the CPLD

We don't say "chip select, address offset and length" anywhere else in
this document.  The reg format expected by the parent node should be
documented in the binding for the parent node (e.g. you could find the
node with a different reg format if for some reason it's not under a
localbus node, such as may happen in certain virtualization
scenarios).  

All you need to say here is that there is one reg region, which
describes the CPLD registers.


> +Example:
> + cpld@3,0 {
> + #address-cells = <1>;
> + #size-cells = <1>;

Why do you need #address-cells/#size-cells?

If you do need them, where is ranges and/or a description of what the
child reg format is?

-Scott


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] devicetree/bindings: Add binding for micron n25q512a memory

[Scott Wood]

On Thu, 2014-07-03 at 23:08 -0500, Jain Priyanka-B32167 wrote:
> 
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Friday, July 04, 2014 3:40 AM
> > To: Jain Priyanka-B32167
> > Cc: devicetree@vger.kernel.org; linuxppc-...@lists.ozlabs.org; linux-
> > s...@vger.kernel.org; linux-...@lists.infradead.org
> > Subject: Re: [PATCH] devicetree/bindings: Add binding for micron n25q512a
> > memory
> > 
> > On Thu, 2014-07-03 at 15:42 +0530, Priyanka Jain wrote:
> > > -Micron n25q512a memory is supported by m25p80 driver.
> > >  Add compatible field required to support n25q512a in m25p80.txt -Add
> > > micron to the vendor-prefixes.txt file
> > >
> > > Signed-off-by: Priyanka Jain 
> > > ---
> > >  Documentation/devicetree/bindings/mtd/m25p80.txt   |1 +
> > >  .../devicetree/bindings/vendor-prefixes.txt|1 +
> > >  2 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > Why did you send this to the ppc list but not the spi or mtd lists?
> > 
> [Jain Priyanka-B32167] Sorry, I missed that
> > I'm having a hard time following the flow of how these SPI devices get
> > bound -- is the compatible involved at all?  I don't see this string
> > (with vendor prefix included) in the driver.  I do see a table that
> > contains what looks like device IDs.  If the device can report its id,
> > shouldn't we rely on that rather than device tree compatible?
> > 
> > -Scott
> [Jain Priyanka-B32167]
> Spi driver has a check to device name corresponding to device-id and compare 
> to what is passed in dts string.

Please go into more detail.  I don't see where the string
"micron,n25q512a" appears in the current kernel.  I do see "n25q512a",
but how does that compare successfully with the version of the string
that has a vendor compatible?

Again, is there a device ID that can be read at runtime?  Is there a
compatible string that represents a common programming interface?

> New checkpatch script search for exact string match in binding folder. So, I 
> have added this in example.

That check has a lot of false positives when it comes to compatible
strings for specific chips that don't need to be specifically mentioned
in a more generic binding.

-Scott


--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 2/3] Documentation: gpio: Add APM X-Gene SoC GPIO controller DTS binding

[Linus Walleij]

On Mon, Jul 7, 2014 at 8:52 PM, Feng Kan  wrote:
> On Fri, Jul 4, 2014 at 2:28 PM, Linus Walleij  
> wrote:

>> I don't get this either. The only reason would be that this cell
>> should contain flags (such as open collector) the code for using
>> it being inplemented later.
>
> Yes, open drain configuration and mux via pinctrl was something I
> planned for later.

OK but pinctrl is something else. There is also the GPIO
OD configuration, as it modifies the behaviour of how to set
GPIO lines.

(Yes I know the frameworks maybe ought to talk to each other
for such things)

So if you plan to do this, add it to the bindings even if you're not
adding the code for handling it right now.

> There was another reason for this as well, part of the gpio code I read
> was confusing me. So I look through the other gpio documentations and
> found an example that did this as well.
>
> int of_gpio_simple_xlate(struct gpio_chip *gc,
>  const struct of_phandle_args *gpiospec, u32 *flags)
> {
> /*
>  * We're discouraging gpio_cells < 2, since that way you'll have to
>  * write your own xlate function (that will have to retrive the GPIO
>  * number and the flags from a single gpio cell -- this is possible,
>  * but not recommended).
>  */

Hm yeah that's right.

This check was added by Anton in 2008. Anton why did we discourage
onecell GPIOs?

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 4/9] pci: OF: Fix the conversion of IO ranges into IO resources.

[Arnd Bergmann]

On Monday 07 July 2014, Liviu Dudau wrote:
> On Sat, Jul 05, 2014 at 09:46:09PM +0100, Arnd Bergmann wrote:
> > On Saturday 05 July 2014 14:25:52 Rob Herring wrote:
> > > On Tue, Jul 1, 2014 at 1:43 PM, Liviu Dudau  wrote:
> > > > The ranges property for a host bridge controller in DT describes
> > > > the mapping between the PCI bus address and the CPU physical address.
> > > > The resources framework however expects that the IO resources start
> > > > at a pseudo "port" address 0 (zero) and have a maximum size of 
> > > > IO_SPACE_LIMIT.
> > > > The conversion from pci ranges to resources failed to take that into 
> > > > account.
> > > 
> > > I don't think this change is right. There are 2 resources: the PCI bus
> > > addresses and cpu addresses. This function deals with the cpu
> > > addresses. Returning pci addresses for i/o and cpu addresses for
> > > memory is going to be error prone. We probably need both cpu and pci
> > > resources exposed to host controllers.
> > > 
> > > Making the new function only deal with i/o bus resources and naming it
> > > of_pci_range_to_io_resource would be better.
> > 
> > I think you are correct that this change by itself is will break existing
> > drivers that rely on the current behavior of of_pci_range_to_resource,
> > but there is also something wrong with the existing implementation:
> 
> Either I'm very confused or I've managed to confuse everyone else. The I/O
> resources described using CPU addresses *are* using "pseudo" port based
> addresses (or at least that is my understanding and my reading of the code).
> Can you point me to a function that is expecting the IO resource to have
> the start address at the physical address of the mapped space?

pci_v3_preinit() in arch/arm/mach-integrator/pci_v3.c for instance takes
the resource returned by of_pci_range_to_resource and programs the
start and size into hardware registers that expect a physical address
as far as I can tell.

> I was trying to fix exactly this issue, that you cannot use the resource
> structure returned by this function in any call that is expecting an IO
> resource.

I looked at the other drivers briefly, and I think you indeed fix the Tegra
driver with this but break the integrator driver as mentioned above.
The other callers of of_pci_range_to_resource() are apparently not
impacted as they recalculate the values they get.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 0/3] Add R8A7791/Koelsch/Henninger board PCI DT support

[Sergei Shtylyov]

Hello.

On 06/24/2014 10:22 PM, Arnd Bergmann wrote:


Here's the set of 3 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-v3.16-rc2-20140623' tag. Here we add PCI USB device tree support
for the R8A7791-based Koelsch and Henninger boards. As the 'pci-rcar-gen2'
driver device tree support has been merged for 3.16, this patchset can now be
merged too...



[1/3] ARM: shmobile: r8a7791: add internal PCI bridge nodes
[2/3] ARM: shmobile: koelsch: enable internal PCI
[3/3] ARM: shmobile: henninger: enable internal PCI



Acked-by: Arnd Bergmann 


   Simon, what's up with this series? You've merged analogous series for 
R8A7790 but not this one. You followed up to an older version of it, asking me 
to re-post when the driver patch gets merged but it already had been merged 
already (and this version posted), and I got no reply from you then...


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 00/10] drm: exynos: few patches to enhance bridge chip support

[Doug Anderson]

Hi,

On Wed, Jul 2, 2014 at 10:19 PM, Andreas Färber  wrote:
> With these 10 patches applied on top of my dt on top of kgene's tree,
> the last U-Boot screen stays visible for ~50 seconds, then the screen
> goes blank, and I can ssh in some time later.
> If I comment out the dp-controller node again, it takes long for the
> kernel boot to graphically proceed but works okay then.
> In both cases there's a gap of ~2900 seconds visible in dmesg.

I would have imagined that this was fixed by (1d80415 clocksource:
exynos_mct: Don't reset the counter during boot and resume).

...that should also fix a long delay at bootup (delay was based on how
much time you spent in U-Boot).
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 00/10] drm: exynos: few patches to enhance bridge chip support

[Doug Anderson]

Andreas,

On Fri, Jul 4, 2014 at 6:06 AM, Andreas Färber  wrote:
>> Doug can help you in adding changes required for tps65090.
>
> Hm, Doug had pointed out an issue with tps65090 in my v1, so I dropped
> it: https://patchwork.kernel.org/patch/4397321/

tps65090 on Spring is nowhere near obvious due to the EC commands that
were available during the Spring timeframe.  See
http://crbug.com/391797 for some details.

-Doug
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/18] power: reset: Add AT91 reset driver

[Jean-Christophe PLAGNIOL-VILLARD]

On 11:06 Fri 04 Jul , Maxime Ripard wrote:
> On Fri, Jul 04, 2014 at 09:14:43AM +0200, Boris BREZILLON wrote:
> > On Fri, 4 Jul 2014 11:08:20 +0800
> > Jean-Christophe PLAGNIOL-VILLARD  wrote:
> > 
> > > 
> > > On Jul 3, 2014, at 10:59 PM, Maxime Ripard 
> > >  wrote:
> > > 
> > > > On Thu, Jul 03, 2014 at 10:39:08PM +0800, Jean-Christophe 
> > > > PLAGNIOL-VILLARD wrote:
> > > >>> +++ b/drivers/power/reset/at91-reset.c
> > > >>> @@ -0,0 +1,202 @@
> > > >>> +/*
> > > >>> + * Atmel AT91 SAM9 SoCs reset code
> > > >>> + *
> > > >>> + * Copyright (C) 2014 Maxime Ripard
> > > >>> + *
> > > >>> + * Maxime Ripard 
> > > >> 
> > > >> you can not own the copyright as it’s basically a copy of other
> > > >> people code
> > > > 
> > > > The previous names are missing, right.
> > > > 
> > > >>> + *
> > > >>> + * This file is licensed under the terms of the GNU General Public
> > > >>> + * License version 2.  This program is licensed "as is" without any
> > > >>> + * warranty of any kind, whether express or implied.
> > > >>> + */
> > > >>> +
> > > >>> +#include 
> > > >>> +#include 
> > > >>> +#include 
> > > >>> +#include 
> > > >>> +#include 
> > > >>> +
> > > >>> +#include 
> > > >>> +
> > > >>> +#include 
> > > >>> +#include 
> > > >>> +
> > > >>> +#define AT91_RSTC_CR 0x00/* Reset Controller Control 
> > > >>> Register */
> > > >>> +#define  AT91_RSTC_PROCRST   BIT(0)  /* Processor 
> > > >>> Reset */
> > > >>> +#define  AT91_RSTC_PERRSTBIT(2)  /* Peripheral 
> > > >>> Reset */
> > > >>> +#define  AT91_RSTC_EXTRSTBIT(3)  /* External 
> > > >>> Reset */
> > > >>> +#define  AT91_RSTC_KEY   (0xa5 << 24)/* KEY Password 
> > > >>> */
> > > >>> +
> > > >>> +#define AT91_RSTC_SR 0x04/* Reset Controller Status 
> > > >>> Register */
> > > >>> +#define  AT91_RSTC_URSTS BIT(0)  /* User Reset 
> > > >>> Status */
> > > >>> +#define  AT91_RSTC_RSTTYPGENMASK(10, 8)  /* Reset Type */
> > > >>> +#define  AT91_RSTC_NRSTL BIT(16) /* NRST Pin 
> > > >>> Level */
> > > >>> +#define  AT91_RSTC_SRCMP BIT(17) /* Software 
> > > >>> Reset Command in Progress */
> > > >>> +
> > > >>> +#define AT91_RSTC_MR 0x08/* Reset Controller Mode 
> > > >>> Register */
> > > >>> +#define  AT91_RSTC_URSTENBIT(0)  /* User Reset 
> > > >>> Enable */
> > > >>> +#define  AT91_RSTC_URSTIEN   BIT(4)  /* User Reset 
> > > >>> Interrupt Enable */
> > > >>> +#define  AT91_RSTC_ERSTL GENMASK(11, 8)  /* External 
> > > >>> Reset Length */
> > > >>> +
> > > >>> +enum reset_type {
> > > >>> + RESET_TYPE_GENERAL  = 0,
> > > >>> + RESET_TYPE_WAKEUP   = 1,
> > > >>> + RESET_TYPE_WATCHDOG = 2,
> > > >>> + RESET_TYPE_SOFTWARE = 3,
> > > >>> + RESET_TYPE_USER = 4,
> > > >>> +};
> > > >>> +
> > > >>> +static void __iomem *at91_ramc_base[2], *at91_rstc_base;
> > > >>> +
> > > >>> +static void at91sam9_restart(enum reboot_mode mode, const char *cmd)
> > > >>> +{
> > > >>> + asm volatile(
> > > >>> + ".balign 32\n\t"
> > > >>> +
> > > >>> + "str%2, [%0, #" __stringify(AT91_SDRAMC_TR) "]\n\t"
> > > >>> + "str%3, [%0, #" __stringify(AT91_SDRAMC_LPR) "]\n\t"
> > > >>> + "str%4, [%1, #" __stringify(AT91_RSTC_CR) "]\n\t"
> > > >>> +
> > > >>> + "b  .\n\t"
> > > >>> + :
> > > >>> + : "r" (at91_ramc_base[0]),
> > > >>> +   "r" (at91_rstc_base),
> > > >>> +   "r" (1),
> > > >>> +   "r" (AT91_SDRAMC_LPCB_POWER_DOWN),
> > > >>> +   "r" (AT91_RSTC_KEY | AT91_RSTC_PERRST | 
> > > >>> AT91_RSTC_PROCRST));
> > > >>> +}
> > > >>> +
> > > >>> +static void at91sam9g45_restart(enum reboot_mode mode, const char 
> > > >>> *cmd)
> > > >>> +{
> > > >>> + asm volatile(
> > > >>> + "cmp%1, #0\n\t"
> > > >>> + "beq1f\n\t"
> > > >>> +
> > > >>> + "ldrr0, [%1]\n\t"
> > > >>> + "cmpr0, #0\n\t"
> > > >>> +
> > > >>> + ".balign 32\n\t"
> > > >>> +
> > > >>> + "1: str %3, [%0, #" 
> > > >>> __stringify(AT91_DDRSDRC_RTR) "]\n\t"
> > > >>> + "   str %4, [%0, #" 
> > > >>> __stringify(AT91_DDRSDRC_RTR) "]\n\t"
> > > >>> + "   strne   %3, [%1, #" 
> > > >>> __stringify(AT91_DDRSDRC_RTR) "]\n\t"
> > > >>> + "   strne   %4, [%1, #" 
> > > >>> __stringify(AT91_DDRSDRC_RTR) "]\n\t"
> > > >>> + "   str %5, [%2, #" __stringify(AT91_RSTC_CR) 
> > > >>> "]\n\t"
> > > >>> +
> > > >>> + "   b   .\n\t"
> > > >>> + :
> > > >>> + : "r" (at91_ramc_base[0]),
> > > >>> +   "r" (at91_ramc_base[1]),
> > > >>> +   "r" (at91_rstc_base),
> > > >>> +   "r" (1)

Re: [PATCH V5 2/3] Documentation: gpio: Add APM X-Gene SoC GPIO controller DTS binding

[Feng Kan]

On Fri, Jul 4, 2014 at 2:28 PM, Linus Walleij  wrote:
> On Mon, Jun 30, 2014 at 2:53 PM, Mark Rutland  wrote:
>> On Thu, Jun 26, 2014 at 11:59:46PM +0100, Feng Kan wrote:
>
>>> +- #gpio-cells: Should be two.
>>> + - first cell is the pin number
>>> + - second cell is used to specify optional parameters (unused)
>>
>> Why is there an unused cell?
>>
>> Why not just make this a single cell if the binding defines no valid
>> parameters?
>
> I don't get this either. The only reason would be that this cell
> should contain flags (such as open collector) the code for using
> it being inplemented later.

Yes, open drain configuration and mux via pinctrl was something I
planned for later.
There was another reason for this as well, part of the gpio code I read
was confusing me. So I look through the other gpio documentations and
found an example that did this as well.

int of_gpio_simple_xlate(struct gpio_chip *gc,
 const struct of_phandle_args *gpiospec, u32 *flags)
{
/*
 * We're discouraging gpio_cells < 2, since that way you'll have to
 * write your own xlate function (that will have to retrive the GPIO
 * number and the flags from a single gpio cell -- this is possible,
 * but not recommended).
 */

Thanks, and please advise me on what to do next.
>
> If the controller is too primitive to use such flags it should be onecell.
>
> Yours,
> Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/4] dt: bindings: add bindings for Broadcom bcm43xx sdio devices

[John W. Linville]

Any word from the devicetree folks?

On Sun, Jun 29, 2014 at 04:16:58PM +0200, Hans de Goede wrote:
> From: Arend van Spriel 
> 
> The Broadcom bcm43xx sdio devices are fullmac devices that may be
> integrated in ARM platforms. Currently, the brcmfmac driver for
> these devices support use of platform data. This patch specifies
> the bindings that allow this platform data to be expressed in the
> devicetree.
> 
> Reviewed-by: Hante Meuleman 
> Reviewed-by: Franky (Zhenhui) Lin 
> Reviewed-by: Daniel (Deognyoun) Kim 
> Reviewed-by: Pieter-Paul Giesberts 
> Signed-off-by: Arend van Spriel 
> [hdego...@redhat.com: drop clk / reg_on gpio handling, as there is no 
> consensus
>  on how to handle this yet]
> [hdego...@redhat.com: move from bindings/staging to bindings]
> Signed-off-by: Hans de Goede 
> ---
>  .../bindings/net/wireless/brcm,bcm43xx-fmac.txt| 41 
> ++
>  1 file changed, 41 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt 
> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> new file mode 100644
> index 000..5dbf169
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> @@ -0,0 +1,41 @@
> +Broadcom BCM43xx Fullmac wireless SDIO devices
> +
> +This node provides properties for controlling the Broadcom wireless device. 
> The
> +node is expected to be specified as a child node to the SDIO controller that
> +connects the device to the system.
> +
> +Required properties:
> +
> + - compatible : Should be "brcm,bcm4329-fmac".
> +
> +Optional properties:
> + - brcm,drive-strength : drive strength used for SDIO pins on device in mA
> + (default = 6).
> + - interrupt-parent : the phandle for the interrupt controller to which the
> + device interrupts are connected.
> + - interrupts : specifies attributes for the out-of-band interrupt 
> (host-wake).
> + When not specified the device will use in-band SDIO interrupts.
> + - interrupt-names : name of the out-of-band interrupt, which must be set
> + to "host-wake".
> +
> +Example:
> +
> +mmc3: mmc@01c12000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc3_pins_a>;
> + vmmc-supply = <®_vmmc3>;
> + bus-width = <4>;
> + non-removable;
> + status = "okay";
> +
> + brcmf: bcrmf@1 {
> + reg = <1>;
> + compatible = "brcm,bcm4329-fmac";
> + interrupt-parent = <&pio>;
> + interrupts = <10 8>; /* PH10 / EINT10 */
> + interrupt-names = "host-wake";
> + };
> +};
> -- 
> 2.0.0
> 
> 

-- 
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com  might be all we have.  Be ready.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/13] uio_pruss: add support for devicetree and am33xx

[Paul Walmsley]

On Mon, 7 Jul 2014, Andre Heider wrote:

> On Sun, Jun 29, 2014 at 06:21:34PM +0200, Andre Heider wrote:
> > 
> > this series adds PRUv2 support to uio_pruss through devicetree, makes the
> > device usable on am33xx and enables it on beaglebone black.
> > Inspired by old patches from Matt Porter found in a downstream tree.
> > 
> > To archieve that this series:
> > * adds a flag to omap_hwmod.c to get PRUSS out of hardreset (patch 5 and 6)

...

> > * is the hardreset thing I did there the right thing to do? I think the
> >   proper way would be a reset controller (which apparently doesn't yet exist
> >   for this SoC?) and let the driver deassert/assert on probe/remove?
> > * the platform device path has a clk_enable() / clk_put() calls. Are those
> >   now redundant with the introduced pm_runtime_enable() pm_runtime_disable()
> >   calls?

Probably you only need pm_runtime_{get,put}_*() calls, unless you're 
changing clock parents or rates in your driver code.

> @OMAP guys: any comments? The series depends on patch 5 and 6; both touch
> common hwmod code.

I'd suggest splitting the series into three independent pieces if 
possible:

1. UIO code, for the UIO maintainer(s)
2. DT pieces for Tony
3. hwmod pieces for me

That way they can be cleanly merged by the respective maintainers.

As far as the hwmod piece goes, I'd be willing to merge your code as a 
temporary workaround for the issue, and marking it as such; but I'd be 
concerned about power management-related interactions (i.e., does the 
PRUSS need to be reset upon return from deep idle states, etc.)


- Paul
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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/2] gpio: Add driver for Zynq GPIO controller

[Sören Brinkmann]

On Mon, 2014-07-07 at 04:45PM +0200, Linus Walleij wrote:
> On Wed, Jun 18, 2014 at 1:39 PM, Harini Katakam  wrote:
> 
> > From: Harini Katakam 
> >
> > Add support for GPIO controller used by Xilinx Zynq.
> >
> > Signed-off-by: Harini Katakam 
> > Signed-off-by: Soren Brinkmann 
> > ---
> >
> > v2 changes:
> >  - convert to pm_runtime_force_(suspend|resume)
> >  - add pm_runtime_set_active in probe()
> >  - also (un)prepare clocks when they are dis-/enabled
> >  - add some missing calls to pm_runtime_get()
> >  - use pm_runtime_put() instead of sync variant
> >  - remove gpio chip in driver remove()
> >  - remove redundant type casts
> >  - directly use IO helpers
> >  - use BIT macro to set/clear bits
> >  - migrate to GPIOLIB_IRQCHIP
> 
> This is a great improvement! Only small stuff remains.
> 
> > +#include 
> > +#include 
> > +#include 
> 
> This should be:
> #include 
> 
> If that doesn't work ... why?
Works just fine.

> 
> > +/**
> > + * struct zynq_gpio - gpio device private data structure
> > + * @chip:  instance of the gpio_chip
> > + * @base_addr: base address of the GPIO device
> > + * @irq:   irq associated with the controller
> > + * @clk:   clock resource for this controller
> > + */
> > +struct zynq_gpio {
> > +   struct gpio_chip chip;
> > +   void __iomem *base_addr;
> > +   int irq;
> 
> Why is irq kept around in this struct? It looks like it could just
> be a local variable in probe()?
You're right.

I think that were both part of the legacy in this driver.

Sören

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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] ASoC: tas2552: Support TI TAS2552 Amplifier

[Dan Murphy]

Mark
Thanks for the review

On 07/07/2014 03:08 AM, Mark Brown wrote:
> On Thu, Jul 03, 2014 at 11:24:35AM -0500, Dan Murphy wrote:
>
>> +static int tas2552_power(struct tas2552_data *data, u8 power)
>> +{
>> +int ret = 0;
>> +
>> +mutex_lock(&data->mutex);
>> +
>> +if (power) {
>> +if (data->enable_gpio)
>> +gpiod_set_value(data->enable_gpio, 1);
>> +
>> +data->power_state = 1;
>> +} else {
>> +if (data->enable_gpio)
>> +gpiod_set_value(data->enable_gpio, 0);
>> +
>> +data->power_state = 0;
>> +}
>> +
>> +mutex_unlock(&data->mutex);
>> +return ret;
>> +}
> I don't understand this function.  It appears to be the only place where
> either power_state or mutex is used so it's just adding some wrapping
> around setting the GPIO value which doesn't seem like it's doing much.
> Why are we tracking power_state?

This function and mutex are artifacts from the development and probably can be 
consolidated
into the runtime PM calls. 

>
>> +static void tas2552_sw_shutdown(struct tas2552_data *tas_data, int 
>> sw_shutdown)
>> +{
>> +u8 cfg1_reg = 0x0;
>> +
>> +if (sw_shutdown)
>> +cfg1_reg |= TAS2552_SWS_MASK;
>> +else
>> +cfg1_reg &= ~TAS2552_SWS_MASK;
>> +
>> +snd_soc_update_bits(tas_data->codec, TAS2552_CFG_1,
>> + TAS2552_SWS_MASK, cfg1_reg);
> Given that you're using _update_bits() clearing the bits in a register
> that was just initialised to zero doesn't make a huge amount of sense.

This was an artifact from RFC in which I was not using the snd_soc functions.
I can remove the initialization of the variable.

>
>> +default:
>> +dev_vdbg(codec->dev, "Substream sample rate is not found\n");
>> +return -EINVAL;
>> +}
> Better to print the rate.

OK

>
>> +pm_runtime_get_sync(codec->dev);
>> +
>> +snd_soc_update_bits(codec, TAS2552_CFG_3, TAS2552_WCLK_MASK, wclk_reg);
>> +
>> +pm_runtime_put(codec->dev);
> This seems really strange - why is the device being powered up to just
> set a bit and then potentially powered down immediately?  I'd expect to
> just update the cache if the device is not active.  You're also not
> checking that the power up worked.

I wanted to make sure that the device was on.  I totally forgot that
the device was using regmap and the values are cached when the device
is not on.

I can remove the get/put around the update calls.

>
>> +
>> +static int tas2552_set_dai_fmt(struct snd_soc_dai *dai, unsigned int fmt)
>> +{
>> +u8 serial_format;
>> +u8 serial_control_mask = 0x00;
>> +if (fmt & SND_SOC_DAIFMT_FORMAT_MASK)
>> +serial_control_mask |= TAS2552_DATA_FORMAT_MASK;
>> +if (serial_control_mask) {
>> +pm_runtime_get_sync(codec->dev);
>> +
>> +snd_soc_update_bits(codec, TAS2552_SER_CTRL_1, 
>> serial_control_mask,
>> +serial_format);
>> +
>> +pm_runtime_put(codec->dev);
>> +}
> This seems broken - if the format mask ever gets set then it won't be
> cleared since we only do an update_bits() if the bit is being set.  Why
> isn't the driver just doing an _update_bits()?

I do not understand what this statement means.

Are you saying snd_soc_update_bits will not clear the bit if the bit mask
is set appropriately?

>
> The comments about runtime PM also apply, they applies throughout the
> driver.
>
>> +static int tas2552_set_dai_sysclk(struct snd_soc_dai *dai, int clk_id,
>> +  unsigned int freq, int dir)
>> +{
>> +struct snd_soc_codec *codec = dai->codec;
>> +
>> +/* Fill in the PLL control registers for J & D
>> + * PLL_CLK = (.5 * freq * J.D) / 2^p
>> + * Need to fill in J and D here based on incoming freq
>> + */
>> +pm_runtime_get_sync(codec->dev);
>> +
>> +snd_soc_update_bits(codec, TAS2552_CFG_2, TAS2552_PLL_ENABLE, 0);
>> +
>> +snd_soc_write(codec, TAS2552_PLL_CTRL_1, 0x10);
>> +snd_soc_write(codec, TAS2552_PLL_CTRL_2, 0x00);
>> +snd_soc_write(codec, TAS2552_PLL_CTRL_3, 0x00);
>> +
>> +snd_soc_update_bits(codec, TAS2552_CFG_2, TAS2552_PLL_ENABLE,
>> +TAS2552_PLL_ENABLE);
>> +
>> +pm_runtime_put(codec->dev);
> This makes no sense at all - please look at what other drivers are doing
> with set_sysclk().  It should be used to get information about how the
> device is clocked.
>
>> +static int tas2552_startup(struct snd_pcm_substream *substream,
>> +   struct snd_soc_dai *dai)
>> +{
>> +struct snd_soc_codec *codec = dai->codec;
>> +
>> +pm_runtime_get_sync(codec->dev);
>> +
>> +/* Turn on Class D amplifier */
>> +snd_soc_update_bits(codec, TAS2552_CFG_2, TAS2552_CLASSD_EN_MASK,
>> +TAS2552_CLASSD_EN);
> This should be done using DAP

Re: [PATCH v2 2/2] devicetree: Add Zynq GPIO devicetree bindings documentation

[Sören Brinkmann]

On Mon, 2014-07-07 at 04:53PM +0200, Linus Walleij wrote:
> On Wed, Jun 18, 2014 at 1:39 PM, Harini Katakam  wrote:
> 
> > From: Harini Katakam 
> >
> > Add gpio-zynq bindings documentation.
> >
> > Signed-off-by: Harini Katakam 
> > Signed-off-by: Soren Brinkmann 
> > ---
> >
> > v2 changes:
> > Improve description.
> (...)
> > +- #gpio-cells  : Should be two. First cell is used to mention
> > + pin number.
> 
> Don't call this "pin number", call it "GPIO line number".
It's also not mentioning the second cell at all. I'll take the part from
gpio-msm to document this property and replace 'pin' with 'GPIO line'.

Sören

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 1/2] libahci: Export some of the libahci functions.

[Suman Tripathi]

This patch exports the function ahci_qc_issue and ahci_start_fis_rx.
The subsequent patches will make use of them.

Signed-off-by: Loc Ho 
Signed-off-by: Suman Tripathi 
---
 drivers/ata/ahci.h| 2 ++
 drivers/ata/libahci.c | 7 ---
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index af63c75..f4a9299 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -370,7 +370,9 @@ int ahci_do_softreset(struct ata_link *link, unsigned int 
*class,
  int pmp, unsigned long deadline,
  int (*check_ready)(struct ata_link *link));

+unsigned int ahci_qc_issue(struct ata_queued_cmd *qc);
 int ahci_stop_engine(struct ata_port *ap);
+void ahci_start_fis_rx(struct ata_port *ap);
 void ahci_start_engine(struct ata_port *ap);
 int ahci_check_ready(struct ata_link *link);
 int ahci_kick_engine(struct ata_port *ap);
diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
index b986145..e6dd89a 100644
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -68,7 +68,6 @@ static ssize_t ahci_transmit_led_message(struct ata_port *ap, 
u32 state,

 static int ahci_scr_read(struct ata_link *link, unsigned int sc_reg, u32 *val);
 static int ahci_scr_write(struct ata_link *link, unsigned int sc_reg, u32 val);
-static unsigned int ahci_qc_issue(struct ata_queued_cmd *qc);
 static bool ahci_qc_fill_rtf(struct ata_queued_cmd *qc);
 static int ahci_port_start(struct ata_port *ap);
 static void ahci_port_stop(struct ata_port *ap);
@@ -615,7 +614,7 @@ int ahci_stop_engine(struct ata_port *ap)
 }
 EXPORT_SYMBOL_GPL(ahci_stop_engine);

-static void ahci_start_fis_rx(struct ata_port *ap)
+void ahci_start_fis_rx(struct ata_port *ap)
 {
void __iomem *port_mmio = ahci_port_base(ap);
struct ahci_host_priv *hpriv = ap->host->private_data;
@@ -641,6 +640,7 @@ static void ahci_start_fis_rx(struct ata_port *ap)
/* flush */
readl(port_mmio + PORT_CMD);
 }
+EXPORT_SYMBOL_GPL(ahci_start_fis_rx);

 static int ahci_stop_fis_rx(struct ata_port *ap)
 {
@@ -1940,7 +1940,7 @@ irqreturn_t ahci_interrupt(int irq, void *dev_instance)
 }
 EXPORT_SYMBOL_GPL(ahci_interrupt);

-static unsigned int ahci_qc_issue(struct ata_queued_cmd *qc)
+unsigned int ahci_qc_issue(struct ata_queued_cmd *qc)
 {
struct ata_port *ap = qc->ap;
void __iomem *port_mmio = ahci_port_base(ap);
@@ -1969,6 +1969,7 @@ static unsigned int ahci_qc_issue(struct ata_queued_cmd 
*qc)

return 0;
 }
+EXPORT_SYMBOL_GPL(ahci_qc_issue);

 static bool ahci_qc_fill_rtf(struct ata_queued_cmd *qc)
 {
--
1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 2/2] ata: Fix the dma state machine lockup for the IDENTIFY DEVICE PIO mode command.

[Suman Tripathi]

This patch fixes the dma state machine lockup due to the processing
of IDENTIFY DEVICE PIO mode command. The X-Gene AHCI controller
has an errata in which it cannot clear the BSY bit after the PIO setup
FIS. The dma state machine enters CMFatalErrorUpdate state and locks
up. This patch also removes the dma restart workaround from the read_id
function as the read_id function is only called by libata layer for
ATA_INTERNAL commands. But for some cases eg: PORT MULTIPLIER
and udev, the framework will enumerate using SCSI commands and it will
not call read_id function.

Signed-off-by: Loc Ho 
Signed-off-by: Suman Tripathi 
---
 drivers/ata/ahci_xgene.c | 60 +---
 1 file changed, 47 insertions(+), 13 deletions(-)

diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
index 77c89bf..81c016a 100644
--- a/drivers/ata/ahci_xgene.c
+++ b/drivers/ata/ahci_xgene.c
@@ -78,6 +78,7 @@
 struct xgene_ahci_context {
struct ahci_host_priv *hpriv;
struct device *dev;
+   u8 last_cmd[MAX_AHCI_CHN_PERCTR]; /* tracking the last command issued*/
void __iomem *csr_core; /* Core CSR address of IP */
void __iomem *csr_diag; /* Diag CSR address of IP */
void __iomem *csr_axi;  /* AXI CSR address of IP */
@@ -98,20 +99,62 @@ static int xgene_ahci_init_memram(struct xgene_ahci_context 
*ctx)
 }

 /**
+ * xgene_ahci_restart_engine - Restart the dma engine.
+ * @ap : ATA port of interest
+ *
+ * Restarts the dma engine inside the controller.
+ */
+static int xgene_ahci_restart_engine(struct ata_port *ap)
+{
+   struct ahci_host_priv *hpriv = ap->host->private_data;
+
+   ahci_stop_engine(ap);
+   ahci_start_fis_rx(ap);
+   hpriv->start_engine(ap);
+
+   return 0;
+}
+
+/**
+ * xgene_ahci_qc_issue - Issue commands to the device
+ * @qc: Command to issue
+ *
+ * Due to Hardware errata for IDENTIFY DEVICE command, the controller cannot
+ * clear the BSY bit after receiving the PIO setup FIS. This results in the dma
+ * state machine goes into the CMFatalErrorUpdate state and locks up. By
+ * restarting the dma engine, it removes the controller out of lock up state.
+ */
+static unsigned int xgene_ahci_qc_issue(struct ata_queued_cmd *qc)
+{
+   struct ata_port *ap = qc->ap;
+   struct ahci_host_priv *hpriv = ap->host->private_data;
+   struct xgene_ahci_context *ctx = hpriv->plat_data;
+   int rc = 0;
+
+   if (unlikely(ctx->last_cmd[ap->port_no] == ATA_CMD_ID_ATA))
+   xgene_ahci_restart_engine(ap);
+
+   rc = ahci_qc_issue(qc);
+
+   /* Save the last command issued */
+   ctx->last_cmd[ap->port_no] = qc->tf.command;
+
+   return rc;
+}
+
+/**
  * xgene_ahci_read_id - Read ID data from the specified device
  * @dev: device
  * @tf: proposed taskfile
  * @id: data buffer
  *
  * This custom read ID function is required due to the fact that the HW
- * does not support DEVSLP and the controller state machine may get stuck
- * after processing the ID query command.
+ * does not support DEVSLP.
  */
 static unsigned int xgene_ahci_read_id(struct ata_device *dev,
   struct ata_taskfile *tf, u16 *id)
 {
u32 err_mask;
-   void __iomem *port_mmio = ahci_port_base(dev->link->ap);

err_mask = ata_do_dev_read_id(dev, tf, id);
if (err_mask)
@@ -133,16 +176,6 @@ static unsigned int xgene_ahci_read_id(struct ata_device 
*dev,
 */
id[ATA_ID_FEATURE_SUPP] &= ~(1 << 8);

-   /*
-* Due to HW errata, restart the port if no other command active.
-* Otherwise the controller may get stuck.
-*/
-   if (!readl(port_mmio + PORT_CMD_ISSUE)) {
-   writel(PORT_CMD_FIS_RX, port_mmio + PORT_CMD);
-   readl(port_mmio + PORT_CMD);/* Force a barrier */
-   writel(PORT_CMD_FIS_RX | PORT_CMD_START, port_mmio + PORT_CMD);
-   readl(port_mmio + PORT_CMD);/* Force a barrier */
-   }
return 0;
 }

@@ -300,6 +333,7 @@ static struct ata_port_operations xgene_ahci_ops = {
.host_stop = xgene_ahci_host_stop,
.hardreset = xgene_ahci_hardreset,
.read_id = xgene_ahci_read_id,
+   .qc_issue = xgene_ahci_qc_issue,
 };

 static const struct ata_port_info xgene_ahci_port_info = {
--
1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 0/2] ata: Fix the dma state machine lockup for APM X-Gene SoC

[Suman Tripathi]

This patch addresses the dma state machine lockup for APM X-Gene SoC.

Signed-off-by: Loc Ho 
Signed-off-by: Suman Tripathi 
---

Suman Tripathi (2):
  libahci: Export some of the libahci functions.
  ata: Fix the dma state machine lockup for the IDENTIFY DEVICE PIO mode
command.

 drivers/ata/ahci.h   |  2 ++
 drivers/ata/ahci_xgene.c | 60 +---
 drivers/ata/libahci.c|  7 +++---
 3 files changed, 53 insertions(+), 16 deletions(-)

--
1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: core: Add DT bindings for card detect debounce time

[Dmitry Torokhov]

On Mon, Jul 7, 2014 at 8:12 AM, Linus Walleij  wrote:
> On Sat, Jun 21, 2014 at 9:22 AM, Alexandre Courbot  wrote:
>
>>> I have added Linus Walleij and Alexandre Courbot, the maintainers of
>>> gpio. Let's see if they can point us in a direction.
>>
>> I agree it would be nice if the debounce value could be handled by the
>> GPIO framework.
>
> I agree too.
>
>> I just wonder what would be the correct way of doing
>> it? Contrary to ACTIVE_LOW and other flags which can be specified with
>> the GPIO phandle, debounce is a numeric value. Maybe using a different
>> property, e.g.:
>>
>> cd-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
>> cd-gpios-debounce = <10>;
>>
>> When looking up a GPIO through gpiod_get(), the GPIO framework could
>> then check for -debounce property and set the debounce time
>> accordingly. At first sight I'd say that would work and could be used
>> for MMC and all other subsystems that need something similar.
>
> Yes, but we also need to write generic debounce handling into
> the gpiolib, so it doesn't matter if the GPIO driver can or cannot
> handle this itself. Some hardware has the capability to debounce
> lines in *hardware*.
>
> Right now a call to gpiod_set_debounce() will fail unless the
> hardware has a debounce option.
>
> What we should really do is make gpiod_set_debounce() always
> work, put the debounce value into the gpio_desc, and move some
> logic similar to what exists in drivers/input/keyboard/gpio_keys.c
> into the gpiolib, then get rid of any local implementations like
> in gpio_keys.
>
> Then we can rely on the gpiolib handling this at all times, and also
> to get the debounce config from DT.
>
> Dmitry, opinions on this?

I am always happy to hear when common functionality is moved into
appropriate layer.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/5] PCI: designware: add rd[wr]_other_conf API

[Murali Karicheri]

On 07/07/2014 12:11 AM, Mohit KUMAR DCG wrote:

Hello Murali,


-Original Message-
From: Murali Karicheri [mailto:m-kariche...@ti.com]
Sent: Tuesday, July 01, 2014 3:15 AM
To: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org;
devicetree@vger.kernel.org
Cc: Murali Karicheri; Santosh Shilimkar; Russell King; Grant Likely; Rob 
Herring;
Mohit KUMAR DCG; Jingoo Han; Bjorn Helgaas; Pratyush ANAND; Richard
Zhu; Kishon Vijay Abraham I; Marek Vasut; Arnd Bergmann; Pawel Moll;
Mark Rutland; Ian Campbell; Kumar Gala; Randy Dunlap
Subject: [PATCH v3 1/5] PCI: designware: add rd[wr]_other_conf API

v3.65 version of the designware h/w, requires application space registers to
be configured to access the remote EP config space.
To support this, add rd[wr]_other_conf API in the pcie_host_opts

Signed-off-by: Murali Karicheri

CC: Santosh Shilimkar
CC: Russell King
CC: Grant Likely
CC: Rob Herring
CC: Mohit Kumar
CC: Jingoo Han
CC: Bjorn Helgaas
CC: Pratyush Anand
CC: Richard Zhu
CC: Kishon Vijay Abraham I
CC: Marek Vasut
CC: Arnd Bergmann
CC: Pawel Moll
CC: Mark Rutland
CC: Ian Campbell
CC: Kumar Gala
CC: Randy Dunlap
CC: Grant Likely
---
  drivers/pci/host/pcie-designware.c |   12 ++--
  drivers/pci/host/pcie-designware.h |4 
  2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-
designware.c
index 1eaf4df..d8f3af7 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -656,7 +656,11 @@ static int dw_pcie_rd_conf(struct pci_bus *bus, u32
devfn, int where,
}

if (bus->number != pp->root_bus_nr)
-   ret = dw_pcie_rd_other_conf(pp, bus, devfn,
+   if (pp->ops->rd_other_conf)
+   ret = pp->ops->rd_other_conf(pp, bus, devfn,
+   where, size, val);
+   else
+   ret = dw_pcie_rd_other_conf(pp, bus, devfn,
where, size, val);
else
ret = dw_pcie_rd_own_conf(pp, where, size, val); @@ -
679,7 +683,11 @@ static int dw_pcie_wr_conf(struct pci_bus *bus, u32
devfn,
return PCIBIOS_DEVICE_NOT_FOUND;

if (bus->number != pp->root_bus_nr)
-   ret = dw_pcie_wr_other_conf(pp, bus, devfn,
+   if (pp->ops->wr_other_conf)
+   ret = pp->ops->wr_other_conf(pp, bus, devfn,
+   where, size, val);
+   else
+   ret = dw_pcie_wr_other_conf(pp, bus, devfn,
where, size, val);
else
ret = dw_pcie_wr_own_conf(pp, where, size, val); diff --git
a/drivers/pci/host/pcie-designware.h b/drivers/pci/host/pcie-designware.h
index 77f592f..8121901 100644
--- a/drivers/pci/host/pcie-designware.h
+++ b/drivers/pci/host/pcie-designware.h
@@ -61,6 +61,10 @@ struct pcie_host_ops {
u32 val, void __iomem *dbi_base);
int (*rd_own_conf)(struct pcie_port *pp, int where, int size, u32
*val);
int (*wr_own_conf)(struct pcie_port *pp, int where, int size, u32
val);
+   int (*rd_other_conf)(struct pcie_port *pp, struct pci_bus *bus,
+   unsigned int devfn, int where, int size, u32 *val);
+   int (*wr_other_conf)(struct pcie_port *pp, struct pci_bus *bus,
+   unsigned int devfn, int where, int size, u32 val);
int (*link_up)(struct pcie_port *pp);
void (*host_init)(struct pcie_port *pp);  };


- Now it looks good to me.

Acked-by: Mohit Kumar

Regards
Mohit

--
1.7.9.5



Mohit,

Thanks.

Jingoo, could you provide your response or Ack?

Thanks
Murali
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/5] PCI: designware: refactor MSI code to work with v3.65 dw hardware

[Murali Karicheri]

On 07/07/2014 12:17 AM, Mohit KUMAR DCG wrote:

Hello Murali,


-Original Message-
From: Murali Karicheri [mailto:m-kariche...@ti.com]
Sent: Tuesday, July 01, 2014 3:15 AM
To: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org;
devicetree@vger.kernel.org
Cc: Murali Karicheri; Santosh Shilimkar; Russell King; Grant Likely; Rob 
Herring;
Mohit KUMAR DCG; Jingoo Han; Bjorn Helgaas; Pratyush ANAND; Richard
Zhu; Kishon Vijay Abraham I; Marek Vasut; Arnd Bergmann; Pawel Moll;
Mark Rutland; Ian Campbell; Kumar Gala; Randy Dunlap
Subject: [PATCH v3 2/5] PCI: designware: refactor MSI code to work with
v3.65 dw hardware

Keystone PCI controller is based on v3.65 version of the DW PCI h/w that
implements MSI controller registers in application space compared to the
newer version. This requires updates to the DW core API to support the PCI
controller driver based on this old DW hardware. Add msi_irq_set()/clear()
API functions to allow Set/Clear MSI IRQ enable bit in the application register.
Also the old h/w uses MSI_IRQ register in application register space to raise
MSI IRQ to the RC from EP. Current code uses the standard mechanism as
per PCI spec. So add another API get_msi_data() to get the address of this
register so that common code can be re-used on old h/w.

Signed-off-by: Murali Karicheri

CC: Santosh Shilimkar
CC: Russell King
CC: Grant Likely
CC: Rob Herring
CC: Mohit Kumar
CC: Jingoo Han
CC: Bjorn Helgaas
CC: Pratyush Anand
CC: Richard Zhu
CC: Kishon Vijay Abraham I
CC: Marek Vasut
CC: Arnd Bergmann
CC: Pawel Moll
CC: Mark Rutland
CC: Ian Campbell
CC: Kumar Gala
CC: Randy Dunlap
CC: Grant Likely
---
  drivers/pci/host/pcie-designware.c |   50 ++-
-
  drivers/pci/host/pcie-designware.h |3 +++
  2 files changed, 39 insertions(+), 14 deletions(-)

diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-
designware.c
index d8f3af7..905941c 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -217,27 +217,47 @@ static int find_valid_pos0(struct pcie_port *pp, int
msgvec, int pos, int *pos0)
return 0;
  }

+static void dw_pcie_msi_clear_irq(struct pcie_port *pp, int irq) {
+   unsigned int res, bit, val;
+
+   res = (irq / 32) * 12;
+   bit = irq % 32;
+   dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4,&val);
+   val&= ~(1<<  bit);
+   dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4, val); }
+
  static void clear_irq_range(struct pcie_port *pp, unsigned int irq_base,
unsigned int nvec, unsigned int pos)  {
-   unsigned int i, res, bit, val;
+   unsigned int i;

for (i = 0; i<  nvec; i++) {
irq_set_msi_desc_off(irq_base, i, NULL);
clear_bit(pos + i, pp->msi_irq_in_use);
/* Disable corresponding interrupt on MSI controller */
-   res = ((pos + i) / 32) * 12;
-   bit = (pos + i) % 32;
-   dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res,
4,&val);
-   val&= ~(1<<  bit);
-   dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res,
4, val);
+   if (pp->ops->msi_clear_irq)
+   pp->ops->msi_clear_irq(pp, pos + i);
+   else
+   dw_pcie_msi_clear_irq(pp, pos + i);
}
  }

+static void dw_pcie_msi_set_irq(struct pcie_port *pp, int irq) {
+   unsigned int res, bit, val;
+
+   res = (irq / 32) * 12;
+   bit = irq % 32;
+   dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4,&val);
+   val |= 1<<  bit;
+   dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res, 4, val); }
+
  static int assign_irq(int no_irqs, struct msi_desc *desc, int *pos)  {
-   int res, bit, irq, pos0, pos1, i;
-   u32 val;
+   int irq, pos0, pos1, i;
struct pcie_port *pp = sys_to_pcie(desc->dev->bus->sysdata);

if (!pp) {
@@ -281,11 +301,10 @@ static int assign_irq(int no_irqs, struct msi_desc
*desc, int *pos)
}
set_bit(pos0 + i, pp->msi_irq_in_use);
/*Enable corresponding interrupt in MSI interrupt controller
*/
-   res = ((pos0 + i) / 32) * 12;
-   bit = (pos0 + i) % 32;
-   dw_pcie_rd_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res,
4,&val);
-   val |= 1<<  bit;
-   dw_pcie_wr_own_conf(pp, PCIE_MSI_INTR0_ENABLE + res,
4, val);
+   if (pp->ops->msi_set_irq)
+   pp->ops->msi_set_irq(pp, pos0 + i);
+   else
+   dw_pcie_msi_set_irq(pp, pos0 + i);
}

*pos = pos0;
@@ -353,7 +372,10 @@ static int dw_msi_setup_irq(struct msi_chip *chip,
struct pci_dev *pdev,
 */
desc->msi_attrib.multiple = msgvec;

-   msg.address_lo = virt_to_phys((void *)pp->msi_data);
+   if (pp->ops->get_msi_data)
+   msg.address_lo = pp->ops->get_msi_dat

[RESEND PATCH v3 08/11] ARM: AT91/dt: add alternative pin muxing for sama5d3 lcd pins

[Boris BREZILLON]

Define alternative pin muxing for the LCDC pins.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/boot/dts/sama5d3_lcd.dtsi | 50 ++
 1 file changed, 50 insertions(+)

diff --git a/arch/arm/boot/dts/sama5d3_lcd.dtsi 
b/arch/arm/boot/dts/sama5d3_lcd.dtsi
index 2186b89..9642eef 100644
--- a/arch/arm/boot/dts/sama5d3_lcd.dtsi
+++ b/arch/arm/boot/dts/sama5d3_lcd.dtsi
@@ -82,6 +82,28 @@
 AT91_PIOA 13 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD13 pin */
 AT91_PIOA 14 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD14 pin */
 AT91_PIOA 15 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD15 pin */
+AT91_PIOC 16 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD16 pin */
+AT91_PIOC 17 
AT91_PERIPH_A AT91_PINCTRL_NONE>; /* LCDD17 pin */
+   };
+
+   pinctrl_lcd_rgb666_alt: lcd-rgb-2-alt {
+   atmel,pins =
+   ; /* LCDD17 pin */
};
@@ -104,6 +126,34 @@
 AT91_PIOA 13 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD13 pin */
 AT91_PIOA 14 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD14 pin */
 AT91_PIOA 15 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD15 pin */
+AT91_PIOC 16 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD16 pin */
+AT91_PIOC 17 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD17 pin */
+AT91_PIOC 18 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD18 pin */
+AT91_PIOC 19 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD19 pin */
+AT91_PIOC 20 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD20 pin */
+AT91_PIOC 21 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD21 pin */
+AT91_PIOE 22 
AT91_PERIPH_A AT91_PINCTRL_NONE   /* LCDD22 pin */
+AT91_PIOE 23 
AT91_PERIPH_A AT91_PINCTRL_NONE>; /* LCDD23 pin */
+   };
+
+   pinctrl_lcd_rgb888_alt: lcd-rgb-3-alt {
+   atmel,pins =
+   http://vger.kernel.org/majordomo-info.html

[RESEND PATCH v3 00/11] drm: add support for Atmel HLCDC Display Controller

[Boris BREZILLON]

Hello,

Sorry for the noise, but I forgot to add the LAKML in Cc.

This patch series adds support for Atmel HLCDC (HLCD Controller) available
on some Atmel SoCs (i.e. the sama5d3 family).

The first two versions of this series didn't receive any reviews from DRM
maintainers or experienced DRM developers.
Anyway, I hope I'll get some feedback on this version.

The HLCDC actually provides a Display Controller and a PWM device, hence I
decided to declare an MFD device exposing 2 subdevices: a display
controller and a PWM chip.
This also solves a circular dependency issue preventing HLCDC driver from
unloading.
The HLCDC request a drm_panel device, which request a backlight device
(a PWM backlight), which depends on a PWM which is provided by the HLCDC
driver (hlcdc -> panel -> backlight -> hlcdc (pwm part)).

The current implementation only supports sama5d3 SoCs but other SoCs should
be easily ported by defining new compatible strings and adding HLCDC
description structures for these SoCs.

The drivers supports basic CRTC functionalities, several overlays and an
hardware cursor.

At the moment, it only supports connection to LCD panels through an RGB
connector (defined as an LVDS connector in my implementation), though
connection to other kind of devices (like DRM bridges) can be added later.

It also supports several RGB format on all planes and some YUV formats on
the HEO overlay plane.

Best Regards,

Boris

Changes since v2:
- fix coding style issues (macro indentation)
- make use of GENMASK in several places
- declare regmap config as a static structure
- rework hlcdc plane update API
- rework cursor handling to make use of the new plane update API
- fix backporch config
- do not use devm_regmap_init_mmio_clk to avoid extra clk_enable
  clk disable calls when accessing registers
- explicitely include regmap and clk headers instead of relying on
  atmel-hlcdc.h inclusions
- make the atmel-hlcdc driver depends on CONFIG_OF
- separate DT bindings documentation from driver implementation
- support several pin muxing for HLCDC pins on sama5d3 SoCs

Changes since v1:
- replace the backlight driver by a PWM driver
- make use of drm_panel infrastructure
- split driver code in several subsystem: MFD, PWM and DRM
- add support for overlays
- add support for hardware cursor


Boris BREZILLON (11):
  mfd: add atmel-hlcdc driver
  mfd: add documentation for atmel-hlcdc DT bindings
  pwm: add support for atmel-hlcdc-pwm device
  pwm: add DT bindings documentation for atmel-hlcdc-pwm driver
  drm: add Atmel HLCDC Display Controller support
  drm: add DT bindings documentation for atmel-hlcdc-dc driver
  ARM: AT91/dt: split sama5d3 lcd pin definitions to match RGB mode
configs
  ARM: AT91/dt: add alternative pin muxing for sama5d3 lcd pins
  ARM: at91/dt: define the HLCDC node available on sama5d3 SoCs
  ARM: at91/dt: add LCD panel description to sama5d3xdm.dtsi
  ARM: at91/dt: enable the LCD panel on sama5d3xek boards

 .../devicetree/bindings/drm/atmel-hlcdc-dc.txt |  59 ++
 .../devicetree/bindings/mfd/atmel-hlcdc.txt|  40 ++
 .../devicetree/bindings/pwm/atmel-hlcdc-pwm.txt|  46 ++
 arch/arm/boot/dts/sama5d31ek.dts   |  24 +
 arch/arm/boot/dts/sama5d33ek.dts   |  24 +
 arch/arm/boot/dts/sama5d34ek.dts   |  24 +
 arch/arm/boot/dts/sama5d36ek.dts   |  24 +
 arch/arm/boot/dts/sama5d3_lcd.dtsi | 197 +-
 arch/arm/boot/dts/sama5d3xdm.dtsi  |  43 ++
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/atmel-hlcdc/Kconfig|  11 +
 drivers/gpu/drm/atmel-hlcdc/Makefile   |   7 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 469 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   | 474 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h   | 210 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c| 706 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h| 422 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_panel.c| 351 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c| 729 +
 drivers/mfd/Kconfig|  12 +
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/atmel-hlcdc.c  | 119 
 drivers/pwm/Kconfig|   9 +
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/pwm-atmel-hlcdc.c  | 229 +++
 include/linux/mfd/atmel-hlcdc.h|  78 +++
 27 files changed, 4281 insertions(+), 31 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
 create mode 100644 Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt
 create mode 100644 dr

[RESEND PATCH v3 03/11] pwm: add support for atmel-hlcdc-pwm device

[Boris BREZILLON]

The HLCDC IP available in some Atmel SoCs (i.e. sam9x5i.e. at91sam9n12,
at91sam9x5 family or sama5d3 family) provide a PWM device.

This driver add support for a PWM chip exposing a single PWM device (which
will most likely be used to drive a backlight device).

Signed-off-by: Boris BREZILLON 
---
 drivers/pwm/Kconfig   |   9 ++
 drivers/pwm/Makefile  |   1 +
 drivers/pwm/pwm-atmel-hlcdc.c | 229 ++
 3 files changed, 239 insertions(+)
 create mode 100644 drivers/pwm/pwm-atmel-hlcdc.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 5b34ff2..7186242 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -50,6 +50,15 @@ config PWM_ATMEL
  To compile this driver as a module, choose M here: the module
  will be called pwm-atmel.
 
+config PWM_ATMEL_HLCDC_PWM
+   tristate "Atmel HLCDC PWM support"
+   depends on MFD_ATMEL_HLCDC
+   help
+ Generic PWM framework driver for Atmel HLCDC PWM.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-atmel.
+
 config PWM_ATMEL_TCB
tristate "Atmel TC Block PWM support"
depends on ATMEL_TCLIB && OF
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index e57d2c3..a245519 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_PWM)   += core.o
 obj-$(CONFIG_PWM_SYSFS)+= sysfs.o
 obj-$(CONFIG_PWM_AB8500)   += pwm-ab8500.o
 obj-$(CONFIG_PWM_ATMEL)+= pwm-atmel.o
+obj-$(CONFIG_PWM_ATMEL_HLCDC_PWM)  += pwm-atmel-hlcdc.o
 obj-$(CONFIG_PWM_ATMEL_TCB)+= pwm-atmel-tcb.o
 obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
 obj-$(CONFIG_PWM_CLPS711X) += pwm-clps711x.o
diff --git a/drivers/pwm/pwm-atmel-hlcdc.c b/drivers/pwm/pwm-atmel-hlcdc.c
new file mode 100644
index 000..7f25197
--- /dev/null
+++ b/drivers/pwm/pwm-atmel-hlcdc.c
@@ -0,0 +1,229 @@
+/*
+ * Copyright (C) 2014 Free Electrons
+ * Copyright (C) 2014 Atmel
+ *
+ * Author: Boris BREZILLON 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ATMEL_HLCDC_PWMCVAL_MASK   GENMASK(15, 8)
+#define ATMEL_HLCDC_PWMCVAL(x) ((x << 8) & ATMEL_HLCDC_PWMCVAL_MASK)
+#define ATMEL_HLCDC_PWMPOL BIT(4)
+#define ATMEL_HLCDC_PWMPS_MASK GENMASK(2, 0)
+#define ATMEL_HLCDC_PWMPS_MAX  0x6
+#define ATMEL_HLCDC_PWMPS(x)   ((x) & ATMEL_HLCDC_PWMPS_MASK)
+
+struct atmel_hlcdc_pwm_chip {
+   struct pwm_chip chip;
+   struct atmel_hlcdc *hlcdc;
+   struct clk *cur_clk;
+};
+
+static inline struct atmel_hlcdc_pwm_chip *
+pwm_chip_to_atmel_hlcdc_pwm_chip(struct pwm_chip *chip)
+{
+   return container_of(chip, struct atmel_hlcdc_pwm_chip, chip);
+}
+
+static int atmel_hlcdc_pwm_config(struct pwm_chip *c,
+ struct pwm_device *pwm,
+ int duty_ns, int period_ns)
+{
+   struct atmel_hlcdc_pwm_chip *chip =
+   pwm_chip_to_atmel_hlcdc_pwm_chip(c);
+   struct atmel_hlcdc *hlcdc = chip->hlcdc;
+   struct clk *new_clk = hlcdc->slow_clk;
+   u64 pwmcval = duty_ns * 256;
+   unsigned long clk_freq;
+   u64 clk_period_ns;
+   u32 pwmcfg;
+   int pres;
+
+   clk_freq = clk_get_rate(new_clk);
+   clk_period_ns = 10;
+   clk_period_ns *= 256;
+   do_div(clk_period_ns, clk_freq);
+
+   if (clk_period_ns > period_ns) {
+   new_clk = hlcdc->sys_clk;
+   clk_freq = clk_get_rate(new_clk);
+   clk_period_ns = 10;
+   clk_period_ns *= 256;
+   do_div(clk_period_ns, clk_freq);
+   }
+
+   for (pres = ATMEL_HLCDC_PWMPS_MAX; pres >= 0; pres--) {
+   if ((clk_period_ns << pres) <= period_ns)
+   break;
+   }
+
+   if (pres > ATMEL_HLCDC_PWMPS_MAX)
+   return -EINVAL;
+
+   pwmcfg = ATMEL_HLCDC_PWMPS(pres);
+
+   if (new_clk != chip->cur_clk) {
+   u32 gencfg = 0;
+
+   clk_prepare_enable(new_clk);
+   clk_disable_unprepare(chip->cur_clk);
+   chip->cur_clk = new_clk;
+
+   if (new_clk != hlcdc->slow_clk)
+   gencfg = ATMEL_HLCDC_CLKPWMSEL;
+   regmap_update_bits(

[RESEND PATCH v3 07/11] ARM: AT91/dt: split sama5d3 lcd pin definitions to match RGB mode configs

[Boris BREZILLON]

The HLCDC (HLCD Controller) IP supports 4 different output mode (RGB444,
RGB565, RGB666 and RGB888) and the pin muxing will depend on the chosen
RGB mode.

Split pin definitions to be able to set pin config according to the
selected mode.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/boot/dts/sama5d3_lcd.dtsi | 127 -
 1 file changed, 96 insertions(+), 31 deletions(-)

diff --git a/arch/arm/boot/dts/sama5d3_lcd.dtsi 
b/arch/arm/boot/dts/sama5d3_lcd.dtsi
index 85d3027..2186b89 100644
--- a/arch/arm/boot/dts/sama5d3_lcd.dtsi
+++ b/arch/arm/boot/dts/sama5d3_lcd.dtsi
@@ -15,38 +15,103 @@
apb {
pinctrl@f200 {
lcd {
-   pinctrl_lcd: lcd-0 {
+   pinctrl_lcd_pwm: lcd-pwm-0 {
+   atmel,pins = ;/* LCDPWM */
+   };
+
+   pinctrl_lcd_base: lcd-base-0 {
+   atmel,pins =
+   ; /* LCDPCK */
+   };
+
+   pinctrl_lcd_rgb444: lcd-rgb-0 {
+   atmel,pins =
+   ; /* LCDD11 pin */
+   };
+
+   pinctrl_lcd_rgb565: lcd-rgb-1 {
+   atmel,pins =
+   ; /* LCDD15 pin */
+   };
+
+   pinctrl_lcd_rgb666: lcd-rgb-2 {
+   atmel,pins =
+   ; /* LCDD17 pin */
+   };
+
+   pinctrl_lcd_rgb888: lcd-rgb-3 {
atmel,pins =
-   ; /* PE28 periph C LCDD23 pin */
+   ; /* LCDD23 pin */
};
};
};
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND PATCH v3 04/11] pwm: add DT bindings documentation for atmel-hlcdc-pwm driver

[Boris BREZILLON]

The HLCDC IP available in some Atmel SoCs (i.e. sam9x5i.e. at91sam9n12,
at91sam9x5 family or sama5d3 family) provide a PWM device.

The DT bindings used for this PWM device is following the default 3 cells
bindings described in Documentation/devicetree/bindings/pwm/pwm.txt.

Signed-off-by: Boris BREZILLON 
---
 .../devicetree/bindings/pwm/atmel-hlcdc-pwm.txt| 46 ++
 1 file changed, 46 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt

diff --git a/Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt 
b/Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt
new file mode 100644
index 000..d5fff47
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt
@@ -0,0 +1,46 @@
+Device-Tree bindings for Atmel's HLCDC (High LCD Controller) PWM driver
+
+The Atmel HLCDC PWM is subdevice of the HLCDC MFD device.
+See Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt for more details.
+
+Required properties:
+ - compatible: value should be one of the following:
+   "atmel,hlcdc-pwm"
+ - pinctr-names: the pin control state names. Should contain "default".
+ - pinctrl-0: should contain the pinctrl states described by pinctrl
+   default.
+ - #pwm-cells: should be set to 3. This PWM chip use the default 3 cells
+   bindings defined in Documentation/devicetree/bindings/pwm/pwm.txt.
+   The first cell encodes the PWM id (0 is the only acceptable value here,
+   because the chip only provide one PWM).
+   The second cell encodes the PWM period in nanoseconds.
+   The third cell encodes the PWM flags (the only supported flag is
+   PWM_POLARITY_INVERTED)
+
+Example:
+
+   hlcdc: hlcdc@f003 {
+   compatible = "atmel,sama5d3-hlcdc";
+   reg = <0xf003 0x2000>;
+   clocks = <&lcdc_clk>, <&lcdck>, <&clk32k>;
+   clock-names = "periph_clk","sys_clk", "slow_clk";
+   status = "disabled";
+
+   hlcdc-display-controller {
+   compatible = "atmel,hlcdc-dc";
+   interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
+   pinctrl-names = "default", "rgb-444", "rgb-565", 
"rgb-666", "rgb-888";
+   pinctrl-0 = <&pinctrl_lcd_base>;
+   pinctrl-1 = <&pinctrl_lcd_base &pinctrl_lcd_rgb444>;
+   pinctrl-2 = <&pinctrl_lcd_base &pinctrl_lcd_rgb565>;
+   pinctrl-3 = <&pinctrl_lcd_base &pinctrl_lcd_rgb666>;
+   pinctrl-4 = <&pinctrl_lcd_base &pinctrl_lcd_rgb888>;
+   };
+
+   hlcdc_pwm: hlcdc-pwm {
+   compatible = "atmel,hlcdc-pwm";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_lcd_pwm>;
+   #pwm-cells = <3>;
+   };
+   };
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND PATCH v3 01/11] mfd: add atmel-hlcdc driver

[Boris BREZILLON]

The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
family or sama5d3 family) exposes 2 subdevices:
- a display controller (controlled by a DRM driver)
- a PWM chip

The MFD device provides a regmap and several clocks (those connected
to this hardware block) to its subdevices.

This way concurrent accesses to the iomem range are handled by the regmap
framework, and each subdevice can safely access HLCDC registers.

Signed-off-by: Boris BREZILLON 
---
 drivers/mfd/Kconfig |  12 
 drivers/mfd/Makefile|   1 +
 drivers/mfd/atmel-hlcdc.c   | 119 
 include/linux/mfd/atmel-hlcdc.h |  78 ++
 4 files changed, 210 insertions(+)
 create mode 100644 drivers/mfd/atmel-hlcdc.c
 create mode 100644 include/linux/mfd/atmel-hlcdc.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index ee8204c..75e674f 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -59,6 +59,18 @@ config MFD_AAT2870_CORE
  additional drivers must be enabled in order to use the
  functionality of the device.
 
+config MFD_ATMEL_HLCDC
+   tristate "Atmel HLCDC (HLCD Controller)"
+   select MFD_CORE
+   select REGMAP_MMIO
+   depends on OF
+   help
+ Choose this option if you have an ATMEL SoC with an HLCDC (HLCD
+ Controller) IP (i.e. at91sam9n12, at91sam9x5 family or sama5d3
+ family).
+ This MFD device exposes two subdevices: a PWM chip and a Display
+ Controller.
+
 config MFD_BCM590XX
tristate "Broadcom BCM590xx PMUs"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 8afedba..5f25b0d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -156,6 +156,7 @@ obj-$(CONFIG_MFD_PM8921_CORE)   += pm8921-core.o ssbi.o
 obj-$(CONFIG_TPS65911_COMPARATOR)  += tps65911-comparator.o
 obj-$(CONFIG_MFD_TPS65090) += tps65090.o
 obj-$(CONFIG_MFD_AAT2870_CORE) += aat2870-core.o
+obj-$(CONFIG_MFD_ATMEL_HLCDC)  += atmel-hlcdc.o
 obj-$(CONFIG_MFD_INTEL_MSIC)   += intel_msic.o
 obj-$(CONFIG_MFD_PALMAS)   += palmas.o
 obj-$(CONFIG_MFD_VIPERBOARD)+= viperboard.o
diff --git a/drivers/mfd/atmel-hlcdc.c b/drivers/mfd/atmel-hlcdc.c
new file mode 100644
index 000..381dd06
--- /dev/null
+++ b/drivers/mfd/atmel-hlcdc.c
@@ -0,0 +1,119 @@
+/*
+ * Copyright (C) 2014 Free Electrons
+ * Copyright (C) 2014 Atmel
+ *
+ * Author: Boris BREZILLON 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ATMEL_HLCDC_REG_MAX(0x4000 - 0x4)
+
+static const struct mfd_cell atmel_hlcdc_cells[] = {
+   {
+   .name = "atmel-hlcdc-pwm",
+   .of_compatible = "atmel,hlcdc-pwm",
+   },
+   {
+   .name = "atmel-hlcdc-dc",
+   .of_compatible = "atmel,hlcdc-dc",
+   },
+};
+
+static const struct regmap_config atmel_hlcdc_regmap_config = {
+   .reg_bits = 32,
+   .val_bits = 32,
+   .reg_stride = 4,
+   .max_register = ATMEL_HLCDC_REG_MAX,
+};
+
+static int atmel_hlcdc_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct atmel_hlcdc *hlcdc;
+   struct resource *res;
+   void __iomem *regs;
+
+   hlcdc = devm_kzalloc(dev, sizeof(*hlcdc), GFP_KERNEL);
+   if (!hlcdc)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   regs = devm_ioremap_resource(dev, res);
+   if (IS_ERR(regs))
+   return PTR_ERR(regs);
+
+   hlcdc->periph_clk = devm_clk_get(dev, "periph_clk");
+   if (IS_ERR(hlcdc->periph_clk)) {
+   dev_err(dev, "failed to get peripheral clock\n");
+   return PTR_ERR(hlcdc->periph_clk);
+   }
+
+   hlcdc->sys_clk = devm_clk_get(dev, "sys_clk");
+   if (IS_ERR(hlcdc->sys_clk)) {
+   dev_err(dev, "failed to get system clock\n");
+   return PTR_ERR(hlcdc->sys_clk);
+   }
+
+   hlcdc->slow_clk = devm_clk_get(dev, "slow_clk");
+   if (IS_ERR(hlcdc->slow_clk)) {
+   dev_err(dev, "failed to get slow clock\n");
+   return PTR_ERR(hlcdc->slow_clk);
+   }
+
+   hlcdc->regmap = devm_regmap_init_mmio(dev, regs,
+ &atmel_hlcdc_regmap_config);
+   if (IS_E

[RESEND PATCH v3 10/11] ARM: at91/dt: add LCD panel description to sama5d3xdm.dtsi

[Boris BREZILLON]

Add LCD panel related nodes (backlight, regulators and panel) to sama5d3
Display Module dtsi.

Reference LCD pin muxing used by sama5d3xek boards.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/boot/dts/sama5d3xdm.dtsi | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm/boot/dts/sama5d3xdm.dtsi 
b/arch/arm/boot/dts/sama5d3xdm.dtsi
index 035ab72..690055e 100644
--- a/arch/arm/boot/dts/sama5d3xdm.dtsi
+++ b/arch/arm/boot/dts/sama5d3xdm.dtsi
@@ -36,6 +36,49 @@
};
};
};
+
+   hlcdc: hlcdc@f003 {
+   hlcdc-display-controller {
+   pinctrl-names = "default", "rgb-444", 
"rgb-565", "rgb-666", "rgb-888";
+   pinctrl-0 = <&pinctrl_lcd_base>;
+   pinctrl-1 = <&pinctrl_lcd_base 
&pinctrl_lcd_rgb444>;
+   pinctrl-2 = <&pinctrl_lcd_base 
&pinctrl_lcd_rgb565>;
+   pinctrl-3 = <&pinctrl_lcd_base 
&pinctrl_lcd_rgb666_alt>;
+   pinctrl-4 = <&pinctrl_lcd_base 
&pinctrl_lcd_rgb888_alt>;
+   };
+   };
};
};
+
+   bl_reg: backlight_regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "backlight-power-supply";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   status = "disabled";
+   };
+
+   panel_reg: panel_regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "panel-power-supply";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   status = "disabled";
+   };
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = <&hlcdc_pwm 0 5 0>;
+   brightness-levels = <0 4 8 16 32 64 128 255>;
+   default-brightness-level = <6>;
+   power-supply = <&bl_reg>;
+   status = "disabled";
+   };
+
+   panel: panel {
+   compatible = "foxlink,fl500wvr00-a0t", "simple-panel";
+   backlight = <&backlight>;
+   power-supply = <&panel_reg>;
+   status = "disabled";
+   };
 };
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND PATCH v3 11/11] ARM: at91/dt: enable the LCD panel on sama5d3xek boards

[Boris BREZILLON]

Enable LCD related nodes and reference panel node in the hlcdc (HLCD
Controller) node.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/boot/dts/sama5d31ek.dts | 24 
 arch/arm/boot/dts/sama5d33ek.dts | 24 
 arch/arm/boot/dts/sama5d34ek.dts | 24 
 arch/arm/boot/dts/sama5d36ek.dts | 24 
 4 files changed, 96 insertions(+)

diff --git a/arch/arm/boot/dts/sama5d31ek.dts b/arch/arm/boot/dts/sama5d31ek.dts
index 04eec0d..338f4c3 100644
--- a/arch/arm/boot/dts/sama5d31ek.dts
+++ b/arch/arm/boot/dts/sama5d31ek.dts
@@ -33,6 +33,14 @@
status = "okay";
};
 
+   hlcdc: hlcdc@f003 {
+   status = "okay";
+
+   hlcdc-display-controller {
+   atmel,panel = <&panel 3 0>;
+   };
+   };
+
macb1: ethernet@f802c000 {
status = "okay";
};
@@ -46,6 +54,22 @@
};
};
 
+   bl_reg: backlight_regulator {
+   status = "okay";
+   };
+
+   panel_reg: panel_regulator {
+   status = "okay";
+   };
+
+   backlight: backlight {
+   status = "okay";
+   };
+
+   panel: panel {
+   status = "okay";
+   };
+
sound {
status = "okay";
};
diff --git a/arch/arm/boot/dts/sama5d33ek.dts b/arch/arm/boot/dts/sama5d33ek.dts
index cbd6a3f..f2ab41d 100644
--- a/arch/arm/boot/dts/sama5d33ek.dts
+++ b/arch/arm/boot/dts/sama5d33ek.dts
@@ -36,9 +36,33 @@
macb0: ethernet@f0028000 {
status = "okay";
};
+
+   hlcdc: hlcdc@f003 {
+   status = "okay";
+
+   hlcdc-display-controller {
+   atmel,panel = <&panel 3 0>;
+   };
+   };
};
};
 
+   bl_reg: backlight_regulator {
+   status = "okay";
+   };
+
+   panel_reg: panel_regulator {
+   status = "okay";
+   };
+
+   backlight: backlight {
+   status = "okay";
+   };
+
+   panel: panel {
+   status = "okay";
+   };
+
sound {
status = "okay";
};
diff --git a/arch/arm/boot/dts/sama5d34ek.dts b/arch/arm/boot/dts/sama5d34ek.dts
index 878aa16..0d0049c 100644
--- a/arch/arm/boot/dts/sama5d34ek.dts
+++ b/arch/arm/boot/dts/sama5d34ek.dts
@@ -46,6 +46,14 @@
macb0: ethernet@f0028000 {
status = "okay";
};
+
+   hlcdc: hlcdc@f003 {
+   status = "okay";
+
+   hlcdc-display-controller {
+   atmel,panel = <&panel 3 0>;
+   };
+   };
};
};
 
@@ -56,6 +64,22 @@
};
};
 
+   bl_reg: backlight_regulator {
+   status = "okay";
+   };
+
+   panel_reg: panel_regulator {
+   status = "okay";
+   };
+
+   backlight: backlight {
+   status = "okay";
+   };
+
+   panel: panel {
+   status = "okay";
+   };
+
sound {
status = "okay";
};
diff --git a/arch/arm/boot/dts/sama5d36ek.dts b/arch/arm/boot/dts/sama5d36ek.dts
index 59576c6..8350358 100644
--- a/arch/arm/boot/dts/sama5d36ek.dts
+++ b/arch/arm/boot/dts/sama5d36ek.dts
@@ -41,12 +41,36 @@
status = "okay";
};
 
+   hlcdc: hlcdc@f003 {
+   status = "okay";
+
+   hlcdc-display-controller {
+   atmel,panel = <&panel 3 0>;
+   };
+   };
+
macb1: ethernet@f802c000 {
status = "okay";
};
};
};
 
+   bl_reg: backlight_regulator {
+   status = "okay";
+   };
+
+   panel_reg: panel_regulator {
+   status = "okay";
+   };
+
+   backlight: backlight {
+   status = "okay";
+   };
+
+   panel: panel {
+   status = "okay";
+   };
+
sound {
status = "okay";
};
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND PATCH v3 02/11] mfd: add documentation for atmel-hlcdc DT bindings

[Boris BREZILLON]

The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
family or sama5d3 family) exposes 2 subdevices:
- a display controller (controlled by a DRM driver)
- a PWM chip

This patch adds documentation for atmel-hlcdc DT bindings.

Signed-off-by: Boris BREZILLON 
---
 .../devicetree/bindings/mfd/atmel-hlcdc.txt| 40 ++
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt

diff --git a/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt 
b/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
new file mode 100644
index 000..294048a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
@@ -0,0 +1,40 @@
+Device-Tree bindings for Atmel's HLCDC (High LCD Controller) MFD driver
+
+Required properties:
+ - compatible: value should be one of the following:
+   "atmel,sama5d3-hlcdc"
+ - reg: base address and size of the HLCDC device registers.
+ - clock-names: the name of the 3 clocks requested by the HLCDC device.
+   Should contain "periph_clk", "sys_clk" and "slow_clk".
+ - clocks: should contain the 3 clocks requested by the HLCDC device.
+
+The HLCDC IP exposes two subdevices:
+ - a PWM chip: see Documentation/devicetree/bindings/pwm/atmel-hlcdc-pwm.txt
+ - a Display Controller: see 
Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt
+
+Example:
+
+   hlcdc: hlcdc@f003 {
+   compatible = "atmel,sama5d3-hlcdc";
+   reg = <0xf003 0x2000>;
+   clocks = <&lcdc_clk>, <&lcdck>, <&clk32k>;
+   clock-names = "periph_clk","sys_clk", "slow_clk";
+
+   hlcdc-display-controller {
+   compatible = "atmel,hlcdc-dc";
+   interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
+   pinctrl-names = "default", "rgb-444", "rgb-565", 
"rgb-666", "rgb-888";
+   pinctrl-0 = <&pinctrl_lcd_base>;
+   pinctrl-1 = <&pinctrl_lcd_base &pinctrl_lcd_rgb444>;
+   pinctrl-2 = <&pinctrl_lcd_base &pinctrl_lcd_rgb565>;
+   pinctrl-3 = <&pinctrl_lcd_base &pinctrl_lcd_rgb666>;
+   pinctrl-4 = <&pinctrl_lcd_base &pinctrl_lcd_rgb888>;
+   };
+
+   hlcdc_pwm: hlcdc-pwm {
+   compatible = "atmel,hlcdc-pwm";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_lcd_pwm>;
+   #pwm-cells = <3>;
+   };
+   };
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND PATCH v3 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver

[Boris BREZILLON]

The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
controller device.

The HLCDC block provides a single RGB output port, and only supports LCD
panels connection to LCD panels for now.

The atmel,panel property link the HLCDC RGB output with the LCD panel
connected on this port (note that the HLCDC RGB connector implementation
makes use of the DRM panel framework).

Connection to other external devices (DRM bridges) might be added later by
mean of a new atmel,xxx (atmel,bridge) property.

Signed-off-by: Boris BREZILLON 
---
 .../devicetree/bindings/drm/atmel-hlcdc-dc.txt | 59 ++
 1 file changed, 59 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt

diff --git a/Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt 
b/Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt
new file mode 100644
index 000..594bdb2
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt
@@ -0,0 +1,59 @@
+Device-Tree bindings for Atmel's HLCDC (High LCD Controller) DRM driver
+
+The Atmel HLCDC Display Controller is subdevice of the HLCDC MFD device.
+See Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt for more details.
+
+Required properties:
+ - compatible: value should be one of the following:
+   "atmel,hlcdc-dc"
+ - interrupts: the HLCDC interrupt definition
+ - pinctrl-names: the pin control state names. Should contain "default",
+   "rgb-444", "rgb-565", "rgb-666" and "rgb-888".
+ - pinctrl-[0-4]: should contain the pinctrl states described by pinctrl
+   names.
+ - atmel,panel: Should contain a phandle with 2 parameters.
+   The first cell is a phandle to a DRM panel device
+   The second cell encodes the RGB mode, which can take the following values:
+   * 0: RGB444
+   * 1: RGB565
+   * 2: RGB666
+   * 3: RGB888
+   The third cell encodes specific flags describing LCD signals configuration
+   (see Atmel's datasheet for a full description of these fields):
+   * bit 0: HSPOL: Horizontal Synchronization Pulse Polarity
+   * bit 1: VSPOL: Vertical Synchronization Pulse Polarity
+   * bit 2: VSPDLYS: Vertical Synchronization Pulse Start
+   * bit 3: VSPDLYE: Vertical Synchronization Pulse End
+   * bit 4: DISPPOL: Display Signal Polarity
+   * bit 7: DISPDLY: LCD Controller Display Power Signal Synchronization
+   * bit 12: VSPSU: LCD Controller Vertical synchronization Pulse Setup 
Configuration
+   * bit 13: VSPHO: LCD Controller Vertical synchronization Pulse Hold 
Configuration
+   * bit 16-20: GUARDTIME: LCD DISPLAY Guard Time
+
+Example:
+
+   hlcdc: hlcdc@f003 {
+   compatible = "atmel,sama5d3-hlcdc";
+   reg = <0xf003 0x2000>;
+   clocks = <&lcdc_clk>, <&lcdck>, <&clk32k>;
+   clock-names = "periph_clk","sys_clk", "slow_clk";
+   status = "disabled";
+
+   hlcdc-display-controller {
+   compatible = "atmel,hlcdc-dc";
+   interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
+   pinctrl-names = "default", "rgb-444", "rgb-565", 
"rgb-666", "rgb-888";
+   pinctrl-0 = <&pinctrl_lcd_base>;
+   pinctrl-1 = <&pinctrl_lcd_base &pinctrl_lcd_rgb444>;
+   pinctrl-2 = <&pinctrl_lcd_base &pinctrl_lcd_rgb565>;
+   pinctrl-3 = <&pinctrl_lcd_base &pinctrl_lcd_rgb666>;
+   pinctrl-4 = <&pinctrl_lcd_base &pinctrl_lcd_rgb888>;
+   };
+
+   hlcdc_pwm: hlcdc-pwm {
+   compatible = "atmel,hlcdc-pwm";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_lcd_pwm>;
+   #pwm-cells = <3>;
+   };
+   };
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RESEND PATCH v3 09/11] ARM: at91/dt: define the HLCDC node available on sama5d3 SoCs

[Boris BREZILLON]

Define the HLCDC (HLCD Controller) IP available on some sama5d3 SoCs
(i.e. sama5d31, sama5d33, sama5d34 and sama5d36) in sama5d3 dtsi file.

Signed-off-by: Boris BREZILLON 
---
 arch/arm/boot/dts/sama5d3_lcd.dtsi | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/sama5d3_lcd.dtsi 
b/arch/arm/boot/dts/sama5d3_lcd.dtsi
index 9642eef..f6aa637 100644
--- a/arch/arm/boot/dts/sama5d3_lcd.dtsi
+++ b/arch/arm/boot/dts/sama5d3_lcd.dtsi
@@ -166,6 +166,26 @@
};
};
 
+   hlcdc: hlcdc@f003 {
+   compatible = "atmel,sama5d3-hlcdc";
+   reg = <0xf003 0x2000>;
+   clocks = <&lcdc_clk>, <&lcdck>, <&clk32k>;
+   clock-names = "periph_clk","sys_clk", 
"slow_clk";
+   status = "disabled";
+
+   hlcdc-display-controller {
+   compatible = "atmel,hlcdc-dc";
+   interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
+   };
+
+   hlcdc_pwm: hlcdc-pwm {
+   compatible = "atmel,hlcdc-pwm";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_lcd_pwm>;
+   #pwm-cells = <3>;
+   };
+   };
+
pmc: pmc@fc00 {
periphck {
lcdc_clk: lcdc_clk {
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 8/9] Documentation: devicetree: Document sclk-jpeg clock for exynos3250 SoC

[Jacek Anaszewski]

JPEG IP on Exynos3250 SoC requires enabling two clock
gates for its operation. This patch documents this
requirement.

Signed-off-by: Jacek Anaszewski 
Signed-off-by: Kyungmin Park 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: devicetree@vger.kernel.org
---
 .../bindings/media/exynos-jpeg-codec.txt   |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt 
b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
index 937b755..20cd150 100644
--- a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
+++ b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
@@ -3,9 +3,12 @@ Samsung S5P/EXYNOS SoC series JPEG codec
 Required properties:
 
 - compatible   : should be one of:
- "samsung,s5pv210-jpeg", "samsung,exynos4210-jpeg";
+ "samsung,s5pv210-jpeg", "samsung,exynos4210-jpeg",
+ "samsung,exynos3250-jpeg";
 - reg  : address and length of the JPEG codec IP register set;
 - interrupts   : specifies the JPEG codec IP interrupt;
 - clocks   : should contain the JPEG codec IP gate clock specifier, from 
the
- common clock bindings;
-- clock-names  : should contain "jpeg" entry.
+ common clock bindings; for Exynos3250 SoC special clock gate
+ should be defined as the second element of the clocks array
+- clock-names  : should contain "jpeg" entry and additionally "sclk-jpeg" entry
+ for Exynos3250 SoC
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 9/9] ARM: dts: exynos3250: add JPEG codec device node

[Jacek Anaszewski]

Signed-off-by: Jacek Anaszewski 
Signed-off-by: Kyungmin Park 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: devicetree@vger.kernel.org
---
 arch/arm/boot/dts/exynos3250.dtsi |   12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
b/arch/arm/boot/dts/exynos3250.dtsi
index 3e678fa..351871a 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -206,6 +206,18 @@
interrupts = <0 240 0>;
};
 
+   jpeg-codec@1183 {
+   compatible = "samsung,exynos3250-jpeg";
+   reg = <0x1183 0x1000>;
+   interrupts = <0 171 0>;
+   clocks = <&cmu CLK_JPEG>, <&cmu CLK_SCLK_JPEG>;
+   clock-names = "jpeg", "sclk-jpeg";
+   samsung,power-domain = <&pd_cam>;
+   assigned-clock-parents = <&cmu CLK_MOUT_CAM_BLK &cmu 
CLK_DIV_MPLL_PRE>,
+<&cmu CLK_SCLK_JPEG &cmu>;
+   assigned-clock-rates = <&cmu CLK_SCLK_JPEG 15000>;
+   };
+
mshc_0: mshc@1251 {
compatible = "samsung,exynos5250-dw-mshc";
reg = <0x1251 0x1000>;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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/2] gpio: Add driver for Zynq GPIO controller

[Sören Brinkmann]

Hi Linus,

On Mon, 2014-07-07 at 04:51PM +0200, Linus Walleij wrote:
> On Wed, Jun 18, 2014 at 5:36 PM, Sören Brinkmann
>  wrote:
> 
> > I did some of the changes for this v2 and a few things are not clear to
> > me.
> >
> > The first is, how is userspace supposed to find the correct offset for a
> > GPIO pin.
> 
> The sysfs interface to GPIO is *NOT* *GOOD* this is universally
> agreed upon.
> 
> This needs someone to step in and provide a replacement, my preferred
> mechanism would be a /dev/gpiochip0/... hierarchy using char devices.
> 
> > E.g. let's say GPIO 10 of this SOC-internal GPIO controller is
> > something I want to control. So, I'd export GPIO (chip-base + 10). But
> > this chip-base seems pretty variable. v1 of this patch had it hardcoded
> > to 0, which resulted in a predictable offset, but apparently was utterly
> > wrong. Now I see an offset of 138 for this chip when using my config.
> > And when I use multi_v7_defconfig the offset is somewhere in the 800s,
> > IIRC. The best I found was the 'label' in the gpiochip's sysfs entry,
> > but documentation says that is not necessarily unique, and parsing labes
> > seems sub-optimal too.
> 
> You see. It is badly designed and needs to be rewritten.
> 
> It was merged into the kernel at a time when the GPIO subsystem
> was unmaintained, sadly.
> 
> > The second issue is a stack trace (below) I see when triggering
> > interrupts (e.g. echo rising > edge; and then pushing the connected
> > button). Looking at the stack trace, I don't see an obvious error (I
> > think I pretty much copied the IRQ registration from the gpio-pl061.c
> > driver you mentioned). Is this an issue in this driver or the core code?
> 
> Probably.
> 
> Using GPIOs for IRQs in userspace is an even worse idea than using
> GPIOs from userspace in general :-D
> 
> But before you add any hairy code in userspace, please have a look
> at Documentation/gpio/sysfs.txt:
> 
> "Note that standard kernel drivers exist for common "LEDs and Buttons"
>  GPIO tasks:  "leds-gpio" and "gpio_keys", respectively. Use those
>  instead of talking directly to the GPIOs; they integrate with kernel
>  frameworks better than your userspace code could."
> 
> So: what is the usecase for these GPIOs?

Yea, in this case it was a button. I have to look at these drivers. It's
very likely that they cover what I want. But this case is trivial. I
really don't do anything but enabling the IRQ by writing to the edge
attribute and press the push-button connected to that GPIO line.

But as a general note: I think we have quite some customers trying to do
GPIO in userspace. With Zynq's FPGA portion, a lot of things come down
to make signals accessible in Linux and a lot of people do not want or
need a full blown kernel driver and use GPIO. The request for 'how to
handle GPIO IRQs in userspace' is pretty common. Often this gets passed
on to UIO though.

Thanks for the answers.

Sören

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pinctrl: pinctrl-st.c: Cleaning up values that are never used

[Linus Walleij]

On Thu, Jun 26, 2014 at 3:44 PM, Rickard Strandqvist
 wrote:

> Remove variable that are never used
>
> This was found using a static code analysis program called cppcheck.
>
> Signed-off-by: Rickard Strandqvist 

Patch applied with Patrice's ACK.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pinctrl: pinctrl-single.c: Cleaning up wrong format string usage

[Linus Walleij]

On Thu, Jun 26, 2014 at 6:58 PM, Rickard Strandqvist
 wrote:

> %d in format string used, but the type is unsigned int
>
> This was found using a static code analysis program called cppcheck
>
> Signed-off-by: Rickard Strandqvist 

Patch applied.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pinctrl: pinctrl-single.c: Cleaning up values that are never used

[Linus Walleij]

On Thu, Jun 26, 2014 at 3:43 PM, Rickard Strandqvist
 wrote:

> Remove variable that are never used
>
> This was found using a static code analysis program called cppcheck.
>
> Signed-off-by: Rickard Strandqvist 

Makes sense.

Patch applied unless Tony or Haojian has some better error handling cooking.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pinctrl: pinctrl-at91.c: Cleaning up values that are never used

[Linus Walleij]

On Thu, Jun 26, 2014 at 3:41 PM, Rickard Strandqvist
 wrote:

> Remove variable that are never used
>
> This was found using a static code analysis program called cppcheck.
>
> Signed-off-by: Rickard Strandqvist 
(...)
> -   int ret, val, num_conf = 0;
> +   int val, num_conf = 0;
>
> -   ret = at91_pinconf_get(pctldev, pin_id, &config);
> +   at91_pinconf_get(pctldev, pin_id, &config);

Hm I would have preferred a fix actually checking the ret value,
but the debug show doesn't allow failing, and it's just for
debug anyway...

Patch applied.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pinctrl: pinctrl-st.c: Cleaning up if unsigned is less than zero

[Linus Walleij]

On Thu, Jun 26, 2014 at 1:32 PM, Rickard Strandqvist
 wrote:

> Remove checking if a unsigned is less than zero
>
> This was found using a static code analysis program called cppcheck.
>
> Signed-off-by: Rickard Strandqvist 

Patch applied with the ACKs. Thanks!

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pinctrl: pinctrl-imx1-core.c: Cleaning up if unsigned is less than zero

[Linus Walleij]

On Thu, Jun 26, 2014 at 1:29 PM, Rickard Strandqvist
 wrote:

> Remove checking if a unsigned is less than zero
>
> This was found using a static code analysis program called cppcheck.
>
> Signed-off-by: Rickard Strandqvist 

Patch applied. Thanks!

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pinctrl: pinctrl-imx.c: Cleaning up if unsigned is less than zero

[Linus Walleij]

On Thu, Jun 26, 2014 at 1:28 PM, Rickard Strandqvist
 wrote:

> Remove checking if a unsigned is less than zero
>
> This was found using a static code analysis program called cppcheck.
>
> Signed-off-by: Rickard Strandqvist 

Patch applied. Thanks!

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pinctrl: pinctrl-at91.c: Cleaning up if unsigned is less than zero

[Linus Walleij]

On Thu, Jun 26, 2014 at 1:26 PM, Rickard Strandqvist
 wrote:

> Remove checking if a unsigned is less than zero
>
> This was found using a static code analysis program called cppcheck.
>
> Signed-off-by: Rickard Strandqvist 

Patch applied. Thanks!

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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/9] PCI: Add SPEAr13xx PCie support

[Bartlomiej Zolnierkiewicz]

Hi Arnd,

Any update on status of this patchset?  Is it OK for it to go through
arm-soc tree or should it be splitted into separate parts which would
go through pci/phy/arm-soc trees?

[ The patchset applies fine to next-20140707 after fixing trivial
  reject in drivers/pci/host/Makefile in patch #8.  To make it build
  the following line from patch #8 needs to be dropped:

  +   spin_lock_init(&pp->conf_lock);
]

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

On Thursday, May 22, 2014 05:01:19 PM Pratyush Anand wrote:
> Hi Arnd/Bjorn,
> 
> On Mon, May 19, 2014 at 07:55:12PM +0800, Mohit KUMAR wrote:
> > Hello Arnd,
> > 
> > > -Original Message-
> > > From: Mohit KUMAR DCG
> > > Sent: Tuesday, April 15, 2014 5:20 PM
> > > To: spear-devel; linux-ker...@vger.kernel.org; devicetree@vger.kernel.org;
> > > linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> > > Cc: Mohit KUMAR DCG
> > > Subject: [PATCH V8 0/9] PCI: Add SPEAr13xx PCie support
> > > 
> > > Patch# 1 and 2: Improvement and fixes for SPEAr13xx support.
> > > Patch# 3,4 and 6: Add DT bindings for spear1310/40-miphy, misc and pcie
> > > node Patch# 5: Add spear1310/40-miphy driver and support for spear1310/40
> > > miphy wrapper.
> > > Patch# 7-9: Add SPEAr13xx PCIe driver and dt support.
> > > 
> > > These pathes are tested with linux-3.15 tag of arm-soc tree.
> > > Tested with SPEAr1310 evaluation board with:
> > >   - INTEL PRO 100/100 EP card
> > >   - USB xhci gen2 card
> > >   - Above cards connected through LeCROY PTC switch
> > > 
> > > Modifications for SATA are tested with SPEAr1340-evb board
> > > 
> > 
> > I think 3.16 windows is about to close, are you planning to merge this 
> > series?
> > Pls let me know if something pending on our part.
> 
> If you could let us know the status of this patch series inclusion.
> 
> Regards
> Pratyush
> 
> > 
> > Regards
> > Mohit
> > 
> > > Changes since v7:
> > > - Rebase over for-linus-3.15 tag of arm-soc tree so that complete patch 
> > > series
> > > can be applied cleanly.
> > > - Incorporated few comments on comment style and superfluous comments
> > > Changes since v6:
> > > - Split miphy driver for SPEAr1310 and SPEAr1340
> > > - Some cleanup and incorporated other minor comments Changes since v5:
> > > - Split DT bindings for misc, miphy-40lp and pcie node into sepearte 
> > > patches
> > > - Merge config options PCIE_SPEAR13XX and PCI_MSI into defconfig patch
> > > - Incorporated other minor comments
> > > Changes since v4:
> > > - Uses per device function pointers passed from .data field to
> > >   the of_device_id instead of of_device_is_compatible.
> > > - Incorporated other minor comments from v4
> > > 
> > > Changes since v3:
> > > - Phy driver renamed to phy-miphy40lp
> > > - ahci phy hook patch used as suggested by Arnd
> > > - Incorporated other minor comments from v3
> > > 
> > > Changes since v2:
> > > - Incorporated comments to move SPEAr13xx PCIe and SATA phy specific
> > > routines to
> > >   the phy framework
> > > - Modify ahci driver to include phy hooks
> > > - phy-core driver modifications for subsys_initcall()
> > > 
> > > Changes since v1:
> > > - Few patches of the series are already accepted and applied to mainline 
> > > e.g.
> > >  pcie designware driver improvements,fixes for IO translation bug, PCIe dw
> > > driver maintainer. So dropped these from v2.
> > > - Incorporated comment to move the common/reset PCIe code to the
> > > seperate driver
> > > - PCIe and SATA share common PHY configuration registers, so move SATA
> > > platform code to the system config driver Fourth patch is improves pcie
> > > designware driver and fixes the IO translation bug. IO translation bug fix
> > > leads to the working of PCIe EP devices connected to RC through switch.
> > > 
> > > Mohit Kumar (1):
> > >   SPEAr13xx: defconfig: Update
> > > 
> > > Pratyush Anand (8):
> > >   clk: SPEAr13XX: Fix pcie clock name
> > >   SPEAr13XX: Fix static mapping table
> > >   phy: SPEAr1310/40-miphy: Add binding information
> > >   SPEAr: misc: Add binding information
> > >   phy: SPEAr1310/40-miphy: Add phy driver for PCIe and SATA
> > >   SPEAr13XX: Add binding information for PCIe con

Re: [PATCH v2 1/2] gpio: Add driver for Zynq GPIO controller

[Baruch Siach]

Hi Linux,

On Mon, Jul 07, 2014 at 04:51:56PM +0200, Linus Walleij wrote:
> On Wed, Jun 18, 2014 at 5:36 PM, Sören Brinkmann  
> wrote:
> > The first is, how is userspace supposed to find the correct offset for a
> > GPIO pin.
> 
> The sysfs interface to GPIO is *NOT* *GOOD* this is universally
> agreed upon.
> 
> This needs someone to step in and provide a replacement, my preferred
> mechanism would be a /dev/gpiochip0/... hierarchy using char devices.

I really like the ability to control GPIOs from shell, both interactively and 
scripted. I find it useful for quick hardware level debugging, and for boot 
time scripting (mainly in initramfs). Do you intend to preserve this 
capability in the future? Will I need a special utility (or Busybox applet) to 
do this with char device ioctl?

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 6/7] dt-bindings: add documentation for Mediatek SoC

[Matthias Brugger]

This adds a DT binding documentation for the MT6589 SoC from Mediatek.

Signed-off-by: Matthias Brugger 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/mediatek.txt |8 
 1 file changed, 8 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/mediatek.txt

diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt 
b/Documentation/devicetree/bindings/arm/mediatek.txt
new file mode 100644
index 000..d6ac71f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek.txt
@@ -0,0 +1,8 @@
+Mediatek MT6589 Platforms Device Tree Bindings
+
+Boards with a SoC of the Mediatek MT6589 shall have the following property:
+
+Required root node property:
+
+compatible: must contain "mediatek,mt6589"
+
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 1/7] of: Provide function to request and map memory

[Matthias Brugger]

A call to of_iomap does not request the memory region.
This patch adds the function of_io_request_and_map which requests
the memory region before mapping it.

Signed-off-by: Matthias Brugger 
Suggested-by: Thomas Gleixner 
Suggested-by: Rob Herring 
---
 drivers/of/address.c   |   36 
 include/linux/io.h |2 ++
 include/linux/of_address.h |   11 +++
 lib/devres.c   |2 --
 4 files changed, 49 insertions(+), 2 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 5edfcb0..e371825 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -702,6 +702,42 @@ void __iomem *of_iomap(struct device_node *np, int index)
 }
 EXPORT_SYMBOL(of_iomap);
 
+/*
+ * of_io_request_and_map - Requests a resource and maps the memory mapped IO
+ *for a given device_node
+ * @device:the device whose io range will be mapped
+ * @index: index of the io range
+ * @name:  name of the resource
+ *
+ * Returns a pointer to the requested and mapped memory or an ERR_PTR() encoded
+ * error code on failure. Usage example:
+ *
+ * base = of_io_request_and_map(node, 0, "foo");
+ * if (IS_ERR(base))
+ * return PTR_ERR(base);
+ */
+void __iomem *of_io_request_and_map(struct device_node *np, int index,
+   char *name)
+{
+   struct resource res;
+   void __iomem *mem;
+
+   if (of_address_to_resource(np, index, &res))
+   return IOMEM_ERR_PTR(-EINVAL);
+
+   if (!request_mem_region(res.start, resource_size(&res), name))
+   return IOMEM_ERR_PTR(-EBUSY);
+
+   mem = ioremap(res.start, resource_size(&res));
+   if (!mem) {
+   release_mem_region(res.start, resource_size(&res));
+   return IOMEM_ERR_PTR(-ENOMEM);
+   }
+
+   return mem;
+}
+EXPORT_SYMBOL(of_io_request_and_map);
+
 /**
  * of_dma_get_range - Get DMA range info
  * @np:device node to get DMA range info
diff --git a/include/linux/io.h b/include/linux/io.h
index b76e6e5..d5fc9b8 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -58,6 +58,8 @@ static inline void devm_ioport_unmap(struct device *dev, void 
__iomem *addr)
 }
 #endif
 
+#define IOMEM_ERR_PTR(err) (__force void __iomem *)ERR_PTR(err)
+
 void __iomem *devm_ioremap(struct device *dev, resource_size_t offset,
unsigned long size);
 void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index c13b878..fb7b722 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -109,7 +109,12 @@ static inline bool of_dma_is_coherent(struct device_node 
*np)
 extern int of_address_to_resource(struct device_node *dev, int index,
  struct resource *r);
 void __iomem *of_iomap(struct device_node *node, int index);
+void __iomem *of_io_request_and_map(struct device_node *device,
+   int index, char *name);
 #else
+
+#include 
+
 static inline int of_address_to_resource(struct device_node *dev, int index,
 struct resource *r)
 {
@@ -120,6 +125,12 @@ static inline void __iomem *of_iomap(struct device_node 
*device, int index)
 {
return NULL;
 }
+
+static inline void __iomem *of_io_request_and_map(struct device_node *device,
+   int index, char *name)
+{
+   return IOMEM_ERR_PTR(-EINVAL);
+}
 #endif
 
 #if defined(CONFIG_OF_ADDRESS) && defined(CONFIG_PCI)
diff --git a/lib/devres.c b/lib/devres.c
index f562bf6..bb63248 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -86,8 +86,6 @@ void devm_iounmap(struct device *dev, void __iomem *addr)
 }
 EXPORT_SYMBOL(devm_iounmap);
 
-#define IOMEM_ERR_PTR(err) (__force void __iomem *)ERR_PTR(err)
-
 /**
  * devm_ioremap_resource() - check, request region, and ioremap resource
  * @dev: generic device to handle the resource for
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 2/7] clocksource: Add support for the Mediatek SoCs

[Matthias Brugger]

This patch adds a clock source and clock event for the timer found
on the Mediatek SoCs.

The Mediatek General Purpose Timer block provides five 32 bit timers and
one 64 bit timer.

Two 32 bit timers are used by this driver:
TIMER1: clock events supporting periodic and oneshot events
TIMER2: clock source configured as a free running counter

The General Purpose Timer block can be run with two clocks. A 13 MHz system
clock and the RTC clock running at 32 KHz. This implementation uses the system
clock with no clock source divider.

The interrupts are shared between the different timers and have to be read back
from a register. We just enable one interrupt for the clock event. The clock
event timer is used by all cores.

Signed-off-by: Matthias Brugger 
Acked-by: Thomas Gleixner 
---
 drivers/clocksource/Kconfig |5 +
 drivers/clocksource/Makefile|1 +
 drivers/clocksource/mtk_timer.c |  261 +++
 3 files changed, 267 insertions(+)
 create mode 100644 drivers/clocksource/mtk_timer.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 065131c..1e2fdf0 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -149,6 +149,11 @@ config VF_PIT_TIMER
 config SYS_SUPPORTS_SH_CMT
 bool
 
+config MTK_TIMER
+   select CLKSRC_OF
+   select CLKSRC_MMIO
+   bool
+
 config SYS_SUPPORTS_SH_MTU2
 bool
 
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 800b130..da1ac09 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_CLKSRC_SAMSUNG_PWM)  += samsung_pwm_timer.o
 obj-$(CONFIG_FSL_FTM_TIMER)+= fsl_ftm_timer.o
 obj-$(CONFIG_VF_PIT_TIMER) += vf_pit_timer.o
 obj-$(CONFIG_CLKSRC_QCOM)  += qcom-timer.o
+obj-$(CONFIG_MTK_TIMER)+= mtk_timer.o
 
 obj-$(CONFIG_ARM_ARCH_TIMER)   += arm_arch_timer.o
 obj-$(CONFIG_ARM_GLOBAL_TIMER) += arm_global_timer.o
diff --git a/drivers/clocksource/mtk_timer.c b/drivers/clocksource/mtk_timer.c
new file mode 100644
index 000..32a3d25
--- /dev/null
+++ b/drivers/clocksource/mtk_timer.c
@@ -0,0 +1,261 @@
+/*
+ * Mediatek SoCs General-Purpose Timer handling.
+ *
+ * Copyright (C) 2014 Matthias Brugger
+ *
+ * Matthias Brugger 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GPT_IRQ_EN_REG 0x00
+#define GPT_IRQ_ENABLE(val)BIT((val) - 1)
+#define GPT_IRQ_ACK_REG0x08
+#define GPT_IRQ_ACK(val)   BIT((val) - 1)
+
+#define TIMER_CTRL_REG(val)(0x10 * (val))
+#define TIMER_CTRL_OP(val) (((val) & 0x3) << 4)
+#define TIMER_CTRL_OP_ONESHOT  (0)
+#define TIMER_CTRL_OP_REPEAT   (1)
+#define TIMER_CTRL_OP_FREERUN  (3)
+#define TIMER_CTRL_CLEAR   (2)
+#define TIMER_CTRL_ENABLE  (1)
+#define TIMER_CTRL_DISABLE (0)
+
+#define TIMER_CLK_REG(val) (0x04 + (0x10 * (val)))
+#define TIMER_CLK_SRC(val) (((val) & 0x1) << 4)
+#define TIMER_CLK_SRC_SYS13M   (0)
+#define TIMER_CLK_SRC_RTC32K   (1)
+#define TIMER_CLK_DIV1 (0x0)
+#define TIMER_CLK_DIV2 (0x1)
+
+#define TIMER_CNT_REG(val) (0x08 + (0x10 * (val)))
+#define TIMER_CMP_REG(val) (0x0C + (0x10 * (val)))
+
+#define GPT_CLK_EVT1
+#define GPT_CLK_SRC2
+
+struct mtk_clock_event_device {
+   void __iomem *gpt_base;
+   u32 ticks_per_jiffy;
+   struct clock_event_device dev;
+};
+
+static inline struct mtk_clock_event_device *to_mtk_clk(
+   struct clock_event_device *c)
+{
+   return container_of(c, struct mtk_clock_event_device, dev);
+}
+
+static void mtk_clkevt_time_stop(struct mtk_clock_event_device *evt, u8 timer)
+{
+   u32 val;
+
+   val = readl(evt->gpt_base + TIMER_CTRL_REG(timer));
+   writel(val & ~TIMER_CTRL_ENABLE, evt->gpt_base +
+   TIMER_CTRL_REG(timer));
+}
+
+static void mtk_clkevt_time_setup(struct mtk_clock_event_device *evt,
+   unsigned long delay, u8 timer)
+{
+   writel(delay, evt->gpt_base + TIMER_CMP_REG(timer));
+}
+
+static void mtk_clkevt_time_start(struct mtk_clock_event_device *evt,
+   bool periodic, u8 timer)
+{
+   u32 val;
+
+   /* Acknowledge interrupt */
+   writel(GPT_IRQ_ACK(timer), evt->gpt_base + GPT_IRQ_ACK_REG);
+
+   val = readl(evt->gpt_base + TIMER_CTRL_REG(timer));
+
+   /* Clea

[PATCH v10 5/7] arm: add basic support for Mediatek MT6589 boards

[Matthias Brugger]

This adds a generic devicetree board file and a dtsi for boards
based on MT6589 SoCs from Mediatek.

Apart from the generic parts (gic, clocks) the only component
currently supported are the timers.

Signed-off-by: Matthias Brugger 
---
 arch/arm/Kconfig  |2 +
 arch/arm/Makefile |1 +
 arch/arm/boot/dts/mt6589.dtsi |   94 +
 arch/arm/mach-mediatek/Kconfig|6 +++
 arch/arm/mach-mediatek/Makefile   |1 +
 arch/arm/mach-mediatek/mediatek.c |   27 +++
 6 files changed, 131 insertions(+)
 create mode 100644 arch/arm/boot/dts/mt6589.dtsi
 create mode 100644 arch/arm/mach-mediatek/Kconfig
 create mode 100644 arch/arm/mach-mediatek/Makefile
 create mode 100644 arch/arm/mach-mediatek/mediatek.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 87b63fd..845c12d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -978,6 +978,8 @@ source "arch/arm/mach-mv78xx0/Kconfig"
 
 source "arch/arm/mach-imx/Kconfig"
 
+source "arch/arm/mach-mediatek/Kconfig"
+
 source "arch/arm/mach-mxs/Kconfig"
 
 source "arch/arm/mach-netx/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 6721fab..1895de2 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -172,6 +172,7 @@ machine-$(CONFIG_ARCH_MSM)  += msm
 machine-$(CONFIG_ARCH_MV78XX0) += mv78xx0
 machine-$(CONFIG_ARCH_MVEBU)   += mvebu
 machine-$(CONFIG_ARCH_MXC) += imx
+machine-$(CONFIG_ARCH_MEDIATEK)+= mediatek
 machine-$(CONFIG_ARCH_MXS) += mxs
 machine-$(CONFIG_ARCH_NETX)+= netx
 machine-$(CONFIG_ARCH_NOMADIK) += nomadik
diff --git a/arch/arm/boot/dts/mt6589.dtsi b/arch/arm/boot/dts/mt6589.dtsi
new file mode 100644
index 000..d0297a0
--- /dev/null
+++ b/arch/arm/boot/dts/mt6589.dtsi
@@ -0,0 +1,94 @@
+/*
+ * Copyright (c) 2014 MundoReader S.L.
+ * Author: Matthias Brugger 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include "skeleton.dtsi"
+
+/ {
+   compatible = "mediatek,mt6589";
+   interrupt-parent = <&gic>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x0>;
+   };
+   cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x1>;
+   };
+   cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x2>;
+   };
+   cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x3>;
+   };
+
+   };
+
+   clocks {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "simple-bus";
+   ranges;
+
+   system_clk: dummy13m {
+   compatible = "fixed-clock";
+   clock-frequency = <1300>;
+   #clock-cells = <0>;
+   };
+
+   rtc_clk: dummy32k {
+   compatible = "fixed-clock";
+   clock-frequency = <32000>;
+   #clock-cells = <0>;
+   };
+   };
+
+   soc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "simple-bus";
+   ranges;
+
+   timer: timer@10008000 {
+   compatible = "mediatek,mt6577-timer";
+   reg = <0x10008000 0x80>;
+   interrupts = ;
+   clocks = <&system_clk>, <&rtc_clk>;
+   clock-names = "system-clk", "rtc-clk";
+   };
+
+   gic: interrupt-controller@10212000 {
+   compatible = "arm,cortex-a15-gic";
+   interrupt-controller;
+   #interrupt-cells = <3>;
+   reg = <0x10211000 0x1000>,
+ <0x10212000 0x1000>,
+ <0x10214000 0x2000>,
+ <0x10216000 0x2000>;
+   };
+   };
+};
diff --git a/arch/arm/mach-mediatek/Kconfig b/arch/arm/mach-mediate

[PATCH v10 4/7] vendor-prefixes: add prefix for Mediatek Inc.

[Matthias Brugger]

Signed-off-by: Matthias Brugger 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 4d7f375..d819d8d 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -77,6 +77,7 @@ lsi   LSI Corp. (LSI Logic)
 lltc   Linear Technology Corporation
 marvellMarvell Technology Group Ltd.
 maxim  Maxim Integrated Products
+mediatek   MediaTek Inc.
 micrel Micrel Inc.
 microchip  Microchip Technology Inc.
 mosaixtech Mosaix Technologies, Inc.
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 3/7] dt-bindings: add mtk-timer bindings

[Matthias Brugger]

Add binding documentation for the General Porpose Timer driver of
the Mediatek SoCs.

Signed-off-by: Matthias Brugger 
Acked-by: Sören Brinkmann 
Acked-by: Rob Herring 
---
 .../bindings/timer/mediatek,mtk-timer.txt  |   17 +
 1 file changed, 17 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt

diff --git a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt 
b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt
new file mode 100644
index 000..7c4408f
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt
@@ -0,0 +1,17 @@
+Mediatek MT6577, MT6572 and MT6589 Timers
+---
+
+Required properties:
+- compatible: Should be "mediatek,mt6577-timer"
+- reg: Should contain location and length for timers register.
+- clocks: Clocks driving the timer hardware. This list should include two
+   clocks. The order is system clock and as second clock the RTC clock.
+
+Examples:
+
+   timer@10008000 {
+   compatible = "mediatek,mt6577-timer";
+   reg = <0x10008000 0x80>;
+   interrupts = ;
+   clocks = <&system_clk>, <&rtc_clk>;
+   };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 7/7] arm: mediatek: add dts for Aquaris5 mobile phone

[Matthias Brugger]

The Aquaris5 is a mobile phone based on the MT6589 SoC.

Signed-off-by: Matthias Brugger 
---
 arch/arm/boot/dts/mt6589-aquaris5.dts |   25 +
 1 file changed, 25 insertions(+)
 create mode 100644 arch/arm/boot/dts/mt6589-aquaris5.dts

diff --git a/arch/arm/boot/dts/mt6589-aquaris5.dts 
b/arch/arm/boot/dts/mt6589-aquaris5.dts
new file mode 100644
index 000..443b446
--- /dev/null
+++ b/arch/arm/boot/dts/mt6589-aquaris5.dts
@@ -0,0 +1,25 @@
+/*
+ * Copyright (c) 2014 MundoReader S.L.
+ * Author: Matthias Brugger 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/dts-v1/;
+#include "mt6589.dtsi"
+
+/ {
+   model = "bq Aquaris5";
+
+   memory {
+   reg = <0x8000 0x4000>;
+   };
+};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html