Hello Rahul,
On 2013년 06월 11일 23:11, Rahul Sharma wrote:
> Exynos hdmi IP version is named after hdmi specification version i.e.
> 1.3 and 1.4. This versioning mechanism is not sufficient to handle
> the diversity in the hdmi/phy IPs which are present across the exynos
> SoC family.
>
> This patc
Hello Kishon,
On 2013년 06월 13일 21:54, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:
>>
>>
>>> -Original Message-
>>> From: Sylwester Nawrocki [mailto:s.nawro...@samsung.com]
>>> Sent: Thursday, June 13, 2013 5:56 PM
>>> To: Rahul Sharma
>>> Cc:
On 06/12/2013 03:55 PM, Kishon Vijay Abraham I wrote:
> Hi Chanwoo Choi,
>
> On Wednesday 12 June 2013 07:09 AM, Chanwoo Choi wrote:
>> From: Kishon Vijay Abraham I
>>
>> Added an API of_extcon_get_extcon_dev() to be used by drivers to get
>> extcon device in the case of dt boot (this can be used
On Fri, Jun 14, 2013 at 2:29 AM, Stephen Warren wrote:
> From: Stephen Warren
>
> This property is no longer required by the GPIO binding. Remove it.
>
> Signed-off-by: Stephen Warren
> ---
> This should presumably be applied along with the previous changes
> ---
> arch/arm/boot/dts/spear1310.d
Hi Zhangfei,
On Tue, Jun 11, 2013 at 10:37:10AM +0800, Zhangfei Gao wrote:
> rx-fifo-size and tx-fifo-size will be updated if provided from dts
>
> Signed-off-by: Zhangfei Gao
> CC: Baruch Siach
Acked-by: Baruch Siach
> ---
> .../devicetree/bindings/i2c/i2c-designware.txt |7 +++
On Thu, 13 Jun 2013, Olof Johansson wrote:
> > + u32 status = readl_relaxed(info->baseaddr + PWC_STATUS);
>
> Why readl_relaxed() here? Can't you use a normal readl()?
Unfortunately, on ARM readl_relaxed() _is_ the normal readl() because
the actual readl() may have side effects. See commit 7
LED2 to LED4 are GPIO LEDs. Add corresponding DT nodes.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7779-marzen-reference.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7779-marzen-reference.dts
b/arch/arm/boot/dts/r8a7779-marzen-refere
LED1 to LED4 are GPIO LEDs. Add corresponding DT nodes.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
b/arch/arm/boot/dts/r8
Reference the st1232 reset GPIO from the device tree and remove it from
board code.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts | 2 ++
arch/arm/mach-shmobile/board-armadillo800eva-reference.c | 7 ---
2 files changed, 2 insertions(+), 7 delet
Replace the pinctrl mappings in board code by device tree mappings.
For devices that are still instantiated from board code reference the
mappings as the default pin controller state to apply them at boot time.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7779-marzen-reference.dts |
On Thu, Jun 13, 2013 at 11:49 PM, Collins, Rod
wrote:
> Grant
>
> What is considered the correct way to include the blob in the build so
> that it is not removed?
Don't put it in an __init section. :-p
However, I realized that the .dtb.S target does exactly that under the
assumption that multip
Add a pfc node to the r8a7790 device tree.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7790.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 339d9b1..13caf12 100644
--- a/arch/arm/boot/dts/r8a7790.dts
Add GPIO controller nodes to the r8a7790 core device tree.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7790.dtsi | 61 ++
1 file changed, 61 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 13ca
Add a pfc node to the sh73a0 device tree and remove manual pinmux
initialization from the corresponding board files.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/sh73a0.dtsi | 8
arch/arm/mach-shmobile/board-kzm9g-reference.c | 27 +-
2
Replace the pinctrl mappings in board code by device tree mappings.
For devices that are still instantiated from board code reference the
mappings as the default pin controller state to apply them at boot time.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7740-armadillo800eva-referen
Add a pfc node to the sh7372 device tree.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/sh7372.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sh7372.dtsi b/arch/arm/boot/dts/sh7372.dtsi
index 677fc60..ce19398 100644
--- a/arch/arm/boot/dts/sh7372.dtsi
Add pin mappings for the st1232 device to the device tree and reference
them as the default state for the device.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7740-armad
Add a pfc node to the r8a7778 device tree.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7778.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index 4743735..c8dbf14 100644
--- a/arch/arm/boot/dts/r8a7778.dts
Add GPIO controller nodes to the r8a7779 core device tree.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7779.dtsi | 71 ++
1 file changed, 71 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 9dfc
Add a pfc node to the r8a7779 device tree and remove manual pinmux
initialization from the corresponding board files.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7779.dtsi | 5 +
arch/arm/mach-shmobile/board-marzen-reference.c | 17 -
2 files ch
Add a pfc node to the r8a7740 device tree and remove manual pinmux
initialization from the corresponding board files.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7740.dtsi | 8
arch/arm/mach-shmobile/board-armadillo800eva-reference.c | 16
Add GPIO controller nodes to the r8a7778 core device tree.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7778.dtsi | 51 ++
1 file changed, 51 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index c8db
Add a pfc node to the r8a73a4 device tree.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a73a4.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/r8a73a4.dtsi b/arch/arm/boot/dts/r8a73a4.dtsi
index 4ff2019..5aa1180 100644
--- a/arch/arm/boot/dts/r8a73a4.d
Support device instantiation through the device tree. The compatible
property is used to select the SoC pinmux information.
Set the gpio_chip device field to the PFC device to enable automatic
GPIO OF support.
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Laurent Pinchart
---
.../bindi
Platform data isn't used, support can thus be removed.
Signed-off-by: Laurent Pinchart
Acked-by: Linus Walleij
---
drivers/pinctrl/sh-pfc/core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/core.c b/drivers/pinctrl/sh-pfc/core.c
index 3b2fd43..ac4
Hello,
Here's the sixth version of the SuperH and SH Mobile pin controllers (PFC) DT
support patch set.
The patches are based on tags/renesas-next-20130613 from Simon's tree
(git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git). The result
is available in my tree at
On Thu, Jun 13, 2013 at 11:52 PM, Benjamin Herrenschmidt
wrote:
> On Thu, 2013-06-13 at 23:22 +0100, Grant Likely wrote:
>> Grant Likely (2):
>> dtc: Update generated files to output from Bison 2.5
>> dtc: ensure #line directives don't consume data from the next
>
> Question. Are those
On 06/13/2013 04:52 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-06-13 at 23:22 +0100, Grant Likely wrote:
>> Grant Likely (2):
>> dtc: Update generated files to output from Bison 2.5
>> dtc: ensure #line directives don't consume data from the next
>
> Question. Are those fixes al
On Thu, 2013-06-13 at 23:22 +0100, Grant Likely wrote:
> Grant Likely (2):
> dtc: Update generated files to output from Bison 2.5
> dtc: ensure #line directives don't consume data from the next
Question. Are those fixes also in the upstream dtc from jdl ? Or have we
effectively forked
Hi,
Overall this driver looks like it just needs more cooking
time. It's... gritty. Complicated when it should be simple and
layered. Naming is nonobvious, and overall it's hard to glance at a
function and say "ah, it does ".
I think some of this might be because of naming conventions. Lots of l
Grant
What is considered the correct way to include the blob in the build so
that it is not removed?
Rod
Rod Collins
Principal Software Engineer
Saab Sensis Corporation
315-445-5784
r...@saabsensis.com
-Original Message-
From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behal
Hi James,
On Wednesday 12 June 2013 15:36:59 James Hogan wrote:
> On 11/06/13 23:03, Laurent Pinchart wrote:
> > Document DT properties for the generic pinctrl parameters and add a
> > parser function.
> >
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
> > .../bindings/pinctrl/pinctrl-bin
Hi Grant,
Thanks for the review.
On Wednesday 12 June 2013 13:48:33 Grant Likely wrote:
> On Wed, 12 Jun 2013 00:03:57 +0200, Laurent Pinchart wrote:
> > Document DT properties for the generic pinctrl parameters and add a
> > parser function.
> >
> > Signed-off-by: Laurent Pinchart
> >
> > ---
On Thu, Jun 13, 2013 at 11:08 PM, Stephen Warren wrote:
> On 06/13/2013 03:48 PM, Grant Likely wrote:
>> This patch merely updates the generated dtc parser and lexer files to
>> the output generated by Bison 2.5. The previous versions were generated
>> from version 2.4.1. The only reason for this
Hi Linus,
On Wednesday 12 June 2013 11:24:38 Linus Walleij wrote:
> On Wed, Jun 12, 2013 at 12:22 AM, Laurent Pinchart wrote:
> > Document DT properties for the generic pinctrl parameters and add a
> > parser function.
> >
> > Signed-off-by: Laurent Pinchart
> >
>
> It appears we have a race he
The following changes since commit 317ddd256b9c24b0d78fa8018f80f1e495481a10:
Linux 3.10-rc5 (2013-06-08 17:41:04 -0700)
are available in the git repository at:
git://git.secretlab.ca/git/linux tags/devicetree-for-linus
for you to fetch changes up to 706b78f37fbed8d81b6061359f28a315fb9b1d73:
Add a function to find regions in device tree given a list of nodes to
include and properties to exclude.
See the header file for full documentation.
Signed-off-by: Simon Glass
---
Changes in v3: None
Changes in v2:
- Fix checkpatch checks about parenthesis alignment
include/libfdt.h | 64
This series implemented a verified boot system based around FIT images
as discussed on the U-Boot mailing list, including on this thread:
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/147830
RSA is used to implement the encryption. Images are signed by mkimage
using private keys creat
On 06/13/2013 03:48 PM, Grant Likely wrote:
> This patch merely updates the generated dtc parser and lexer files to
> the output generated by Bison 2.5. The previous versions were generated
> from version 2.4.1. The only reason for this commit is to minimize the
> diff on the next commit which fixe
This patch merely updates the generated dtc parser and lexer files to
the output generated by Bison 2.5. The previous versions were generated
from version 2.4.1. The only reason for this commit is to minimize the
diff on the next commit which fixes a bug in the DTC #line directive
parsing. Otherwis
Previously, the #line parsing regex ended with ({WS}+[0-9]+)?. The {WS}
could match line-break characters. If the #line directive did not contain
the optional flags field at the end, this could cause any integer data on
the next line to be consumed as part of the #line directive parsing. This
could
I've cherry picked this patch from the DTC repository. I've got it in my
device tree merge branch and will be sending it to Linus shortly.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetre
On 06/13/2013 06:55 AM, Christian Ruppert wrote:
> This patch adds the infrastructure required to register non-linear gpio
> ranges through gpiolib and the standard GPIO device tree bindings.
That's not exactly true. The existing gpio-ranges property already
allows non-linear ranges to be represen
From: Stephen Warren
This property is no longer required by the GPIO binding. Remove it.
Signed-off-by: Stephen Warren
---
Assuming the previous patches are accepted, I assume this should be
applied or squashed into the branch where vf610.dtsi was added.
---
arch/arm/boot/dts/vf610.dtsi | 1 -
From: Stephen Warren
Commit bd69f73 "of: Create function for counting number of phandles in
a property" renamed of_parse_phandle_with_args(), and created a wrapper
function that implemented the original name. However, the documentation
of the original function was not moved, leaving it apparently
From: Stephen Warren
Use the new of_parse_phandle_with_fixed_args() to implement the
corrected gpio-ranges DT property definition.
Signed-off-by: Stephen Warren
---
drivers/gpio/gpiolib-of.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpiolib-of.c b/dri
From: Stephen Warren
This property is no longer required by the GPIO binding. Remove it.
Signed-off-by: Stephen Warren
---
This should presumably be applied along with the previous changes
---
arch/arm/boot/dts/spear1310.dtsi | 1 -
arch/arm/boot/dts/spear1340.dtsi | 1 -
arch/arm/boot/dts/spe
From: Stephen Warren
This is identical to of_parse_phandle_with_args(), except that the
number of argument cells is fixed, rather than being parsed out of the
node referenced by each phandle.
Signed-off-by: Stephen Warren
---
drivers/of/base.c | 66
From: Stephen Warren
The gpio-ranges properties in vf610.dtsi were written according to an
older version of the GPIO bindings. Unfortunately, these were changed
incompatibly in commit 86853c8 "gpio: add gpio offset in gpio range
cells property". This patch adds the missing required extra cell in
From: Stephen Warren
This change makes documentation of the the gpio-ranges property shorter
and more succinct, more consistent with the style of the rest of the
document, and not mention Linux-specifics such as the API
pinctrl_request_gpio(); DT binding documents should be OS independant
where a
On Thu, Jun 13, 2013 at 11:25 PM, Alexey Brodkin
wrote:
> On 06/13/2013 10:25 PM, Andy Shevchenko wrote:
>> On Thu, Jun 13, 2013 at 5:37 PM, Alexey Brodkin
>> wrote:
>>> Driver for non-standard on-chip ethernet device ARC EMAC 10/100,
>>> instantiated in some legacy ARC (Synopsys) FPGA Boards suc
From: Joe Perches
Date: Thu, 13 Jun 2013 11:33:21 -0700
> On Thu, 2013-06-13 at 21:25 +0300, Andy Shevchenko wrote:
>> On Thu, Jun 13, 2013 at 5:37 PM, Alexey Brodkin
>> > + if (unlikely((info & OWN_MASK) == FOR_EMAC)) {
>> > + /* BD is still owned by EMAC */
>
On 06/13/2013 03:12 AM, Alexandre Courbot wrote:
> Use a firmware operation to set the CPU reset handler and only resort to
> doing it ourselves if there is none defined.
>
> This supports the booting of secondary CPUs on devices using a TrustZone
> secure monitor.
> diff --git a/arch/arm/mach-te
On 06/13/2013 03:12 AM, Alexandre Courbot wrote:
> Not all Tegra devices need to set the CPU reset handler in the same way.
s/need/can/ ?
> In particular, devices using a TrustZone secure monitor cannot set the
> reset handler directly and need to do it through a firmware operation.
>
> This pat
On 06/13/2013 03:12 AM, Alexandre Courbot wrote:
> Add basic support for booting secondary processors on Tegra devices
> using the Trusted Foundations secure monitor.
>
> Signed-off-by: Alexandre Courbot
> ---
> Documentation/devicetree/bindings/arm/tegra.txt| 11 +
> .../devicetree/bind
On Thu, Jun 13, 2013 at 9:33 PM, Joe Perches wrote:
> On Thu, 2013-06-13 at 21:25 +0300, Andy Shevchenko wrote:
>> On Thu, Jun 13, 2013 at 5:37 PM, Alexey Brodkin
>> wrote:
>> > Driver for non-standard on-chip ethernet device ARC EMAC 10/100,
>> > instantiated in some legacy ARC (Synopsys) FPGA B
On Thu, Jun 13, 2013 at 2:55 PM, Christian Ruppert
wrote:
> This patch adds the infrastructure required to register non-linear gpio
> ranges through gpiolib and the standard GPIO device tree bindings.
>
> Signed-off-by: Christian Ruppert
Splendid. I'll just wait some more time before applying s
On Thu, 2013-06-13 at 21:25 +0300, Andy Shevchenko wrote:
> On Thu, Jun 13, 2013 at 5:37 PM, Alexey Brodkin
> wrote:
> > Driver for non-standard on-chip ethernet device ARC EMAC 10/100,
> > instantiated in some legacy ARC (Synopsys) FPGA Boards such as
> > ARCAngel4/ML50x.
>
> Much better. But st
On Thu, Jun 13, 2013 at 2:55 PM, Christian Ruppert
wrote:
> Traditionally, GPIO ranges are based on consecutive ranges of both GPIO
> and pin numbers. This patch allows for GPIO ranges with arbitrary lists
> of pin numbers.
>
> Signed-off-by: Christian Ruppert
I really like this patch and it se
On Thu, Jun 13, 2013 at 5:37 PM, Alexey Brodkin
wrote:
> Driver for non-standard on-chip ethernet device ARC EMAC 10/100,
> instantiated in some legacy ARC (Synopsys) FPGA Boards such as
> ARCAngel4/ML50x.
Much better. But still few comments below.
> +++ b/drivers/net/ethernet/arc/arc_emac.h
Wh
On Thu, Jun 13, 2013 at 09:29:38AM -0700, Tony Lindgren wrote:
> * Linus Walleij [130613 08:35]:
> > No. If we go down that road *anything* that is connected to a
> > pad becomes part of the pinctrl subsystem, then pinctrl-single
> > becomes some kind of hardware abstraction or BIOS, and that
> >
Hi Grant,
Thanks for the review.
On Wednesday 12 June 2013 12:49:11 Grant Likely wrote:
> On Tue, 21 May 2013 13:40:06 +0200, Laurent Pinchart wrote:
> > Add DT bindings for the gpio-rcar driver and read the device
> > configuration from the DT node at probe time if available.
> >
> > Cc: device
* Linus Walleij [130613 08:35]:
> On Thu, Jun 13, 2013 at 4:41 PM, Balaji T K wrote:
>
> > You mean regulator via pinctrl APIs, I think It will just move the code
> > from omap_hsmmc to a new regulator file with it own init data for pinctrl.
>
> No I'm not saying you should use pinctrl as a "ba
On Thu, 13 Jun 2013, Balaji T K wrote:
> On Thursday 13 June 2013 04:17 PM, Lee Jones wrote:
> >On Thu, 13 Jun 2013, Linus Walleij wrote:
> >
> >>On Thu, Jun 6, 2013 at 9:14 PM, Balaji T K wrote:
> >>
> >>>PBIAS register configuration is based on the regulator voltage
> >>>which supplies these pb
On Thu, Jun 13, 2013 at 4:41 PM, Balaji T K wrote:
>[Me]
>>> This seem so intuitively wrong as it can possibly get, clearly this
>>> is regulator territory.
>
> It is not really a regulator, CONTROL_PBIAS_LITE is just a register
> in control module which configures pad/pin on SOC. In this case PB
I am getting a few
|warning: unused variable ‘p’ [-Wunused-variable]
|warning: unused variable ‘prop’ [-Wunused-variable]
in the case where CONFIG_OF is not defined and the parameters are only
used in the loop macro.
Signed-off-by: Sebastian Andrzej Siewior
---
include/linux/of.h |4 ++--
1
On Thu, Jun 13, 2013 at 10:07 AM, Mark Brown wrote:
> On Thu, Jun 13, 2013 at 09:58:03AM -0500, Nishanth Menon wrote:
>
>> I am proposing moving the following into OF match data.
>> ti,i2c-slave-address
>> ti,i2c-voltage-register
>> ti,i2c-command-register
>> ti,slew-rate-microvolt
>> ti,step-size
On Thu, Jun 13, 2013 at 09:58:03AM -0500, Nishanth Menon wrote:
> I am proposing moving the following into OF match data.
> ti,i2c-slave-address
> ti,i2c-voltage-register
> ti,i2c-command-register
> ti,slew-rate-microvolt
> ti,step-size-micro-volts
> ti,voltage-selector-set-bits
> ti,voltage-selec
On Thursday 13 June 2013 04:17 PM, Lee Jones wrote:
On Thu, 13 Jun 2013, Linus Walleij wrote:
On Thu, Jun 6, 2013 at 9:14 PM, Balaji T K wrote:
PBIAS register configuration is based on the regulator voltage
which supplies these pbias cells, sd i/o pads.
With PBIAS register address and bit de
This adds a generic devicetree board file and a dtsi for boards
based on the RK3066a SoCs from Rockchip.
Apart from the generic parts (gic, clocks, pinctrl) the only components
currently supported are the timers, uarts and mmc ports (all DesignWare-
based).
Signed-off-by: Heiko Stuebner
---
arc
Uarts on all recent Rockchip SoCs are Synopsis DesignWare 8250 types.
Only their addresses vary very much.
This patch adds the necessary definitions to use any of the uart ports
for early debug purposes.
Signed-off-by: Heiko Stuebner
---
arch/arm/Kconfig.debug| 34
This adds a basic clock setup for rk3066a SoCs. Only the gates are
set up currently, as the mux and dividers should use the upcoming
generic devicetree bindings.
Clocks whose rates need to be known are supplied by fixed-rate
"dummy"-clocks that provide the correct rate. This is uncritical insofar
This adds basic support for gate-clocks on Rockchip SoCs.
There are 16 gates in each register and use the HIWORD_MASK
mechanism for changing gate settings.
The gate registers form a continuos block which makes the dt node
structure a matter of taste, as either all 160 gates can be put into
one gat
Fourth version of basic Rockchip A9 support.
Changes since v3:
- split out standalone dw_mmc patches (submitted to linux-mmc)
- Remove divider and mux clocks and use fixed rate clocks instead until
divider and mux clocks have got their generic dt bindings
- Make the gate clock use CLK_OF_DECLARE
On 15:47-20130613, Mark Brown wrote:
> On Thu, Jun 13, 2013 at 08:39:50AM -0500, Nishanth Menon wrote:
>
> > I am having a bit of a difficulty trying to understand your concern
> > here.
>
> Your device tree for this stuff appears to mostly consist of repeating
> the d
Hi,
On Thursday 13 June 2013 20:22:42 Balaji T K wrote:
> On Thursday 13 June 2013 03:32 PM, Laurent Pinchart wrote:
> > On Thursday 13 June 2013 02:53:54 Tony Lindgren wrote:
> >> * Linus Walleij [130613 02:42]:
> >>> On Thu, Jun 6, 2013 at 9:14 PM, Balaji T K wrote:
> PBIAS register confi
On Thursday 13 June 2013 03:32 PM, Laurent Pinchart wrote:
On Thursday 13 June 2013 02:53:54 Tony Lindgren wrote:
* Linus Walleij [130613 02:42]:
On Thu, Jun 6, 2013 at 9:14 PM, Balaji T K wrote:
PBIAS register configuration is based on the regulator voltage
which supplies these pbias cells,
On Thu, Jun 13, 2013 at 08:39:50AM -0500, Nishanth Menon wrote:
> I am having a bit of a difficulty trying to understand your concern
> here.
Your device tree for this stuff appears to mostly consist of repeating
the description of the PMIC that we already have - this really doesn't
seem like a g
On Thursday 13 June 2013 03:23 PM, Tony Lindgren wrote:
* Linus Walleij [130613 02:42]:
On Thu, Jun 6, 2013 at 9:14 PM, Balaji T K wrote:
PBIAS register configuration is based on the regulator voltage
which supplies these pbias cells, sd i/o pads.
With PBIAS register address and bit definiti
On Thu, Jun 13, 2013 at 06:12:23PM +0900, Alexandre Courbot wrote:
> Add basic support for booting secondary processors on Tegra devices
> using the Trusted Foundations secure monitor.
>
> Signed-off-by: Alexandre Courbot
> ---
> Documentation/devicetree/bindings/arm/tegra.txt| 11 +
> .
On Thursday 13 June 2013 22:18:50 Jingoo Han wrote:
> On Wednesday, June 12, 2013 8:23 PM, Arnd Bergmann wrote:
> > On Wednesday 12 June 2013 19:19:05 Jingoo Han wrote:
> > > +
> > > +/* synopsis specific PCIE configuration registers*/
> > > +#define PCIE_PORT_LINK_CONTROL 0x710
> > > +#
On Thursday 13 June 2013 22:22:31 Jingoo Han wrote:
> +struct pcie_port_info {
> + u32 cfg0_size;
> + u32 cfg1_size;
> + u32 io_size;
> + u32 mem_size;
> + phys_addr_t io_bus_addr;
> + phys_addr_t mem_bus_addr;
> +};
>
On 19:01-20130610, Mark Brown wrote:
> On Mon, Jun 10, 2013 at 12:51:42PM -0500, Nishanth Menon wrote:
>
> > a) Tegra seems to use Lookup Table for sending predefinied voltage
> > values to PMIC. OMAP has no concept of lookup table.
>
> They seem to be doing basically the same thing here, you've
Enable PCIe support for Exynos5440 which has two PCIe controllers.
Signed-off-by: Jingoo Han
---
Tested on Exynos5440.
arch/arm/Kconfig |1 +
arch/arm/mach-exynos/Kconfig |2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 42d6ea2.
Exynos5440 has a PCIe controller which can be used as Root Complex.
This driver supports a PCIe controller as Root Complex mode.
Signed-off-by: Surendranath Gurivireddy Balla
Signed-off-by: Siva Reddy Kallam
Signed-off-by: Jingoo Han
---
Tested on Exynos5440.
.../devicetree/bindings/pci/exyno
Exynos5440 has two PCIe controllers which can be used as root complex
for PCIe interface.
Signed-off-by: Jingoo Han
---
Tested on Exynos5440.
arch/arm/boot/dts/exynos5440-ssdk5440.dts |8 ++
arch/arm/boot/dts/exynos5440.dtsi | 40 -
2 files changed,
Hi,
This series of patches introduces PCIe support for Samsung Exynos5440,
and is based on the latest 'linux-next' tree (20130607).
These patches was tested with Intel e1000e LAN card on Exynos5440.
This PATCH v5 follows:
* PATCH v4, sent on June, 12nd 2013
* PATCH v3, sent on June, 6th 2013
*
On Wednesday, June 12, 2013 8:23 PM, Arnd Bergmann wrote:
> On Wednesday 12 June 2013 19:19:05 Jingoo Han wrote:
>
> > +
> > +struct pcie_port {
> > + struct device *dev;
> > + u8 controller;
> > + u8 root_bus_nr;
> > + void __iomem
Hi,
On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:
-Original Message-
From: Sylwester Nawrocki [mailto:s.nawro...@samsung.com]
Sent: Thursday, June 13, 2013 5:56 PM
To: Rahul Sharma
Cc: Rahul Sharma; Inki Dae; linux-samsung-...@vger.kernel.org; devicetree-
disc...@lists.ozlabs.org
Adds USB host support for Beagle-xm.
Roger Quadros (2):
ARM: dts: omap3-beagle-xm: Add USB Host support
ARM: dts: omap3-beagle: Make USB host pin naming consistent
arch/arm/boot/dts/omap3-beagle-xm.dts | 61 +
arch/arm/boot/dts/omap3-beagle.dts| 24 +++
Use a common naming scheme "mode0name.modename flags" for the
USB host pins to be consistent.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle.dts | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for USB host
pins.
CC: Benoît Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 61 +
1 files
On Tue, Jun 11, 2013 at 1:19 AM, Russell King - ARM Linux
wrote:
> On Mon, Jun 10, 2013 at 12:46:59PM +0100, Srinivas KANDAGATLA wrote:
>> > + aux_ctrl = (0x1 << L2X0_AUX_CTRL_SHARE_OVERRIDE_SHIFT) |
>> > + (0x1 << L2X0_AUX_CTRL_DATA_PREFETCH_SHIFT) |
>> > +
On 13/06/13 12:56, Russell King - ARM Linux wrote:
> On Tue, Jun 11, 2013 at 07:50:31AM +0100, Srinivas KANDAGATLA wrote:
>> You are right, It does not make sense to use BIT() macro for field which
>> has more than 1 bit. I think using mix of both BIT() and the old style
>> will make code look bit
On 24/05/13 17:21, James Hogan wrote:
> Add really minimal support for Toumaz Xenif TZ1090 SoC (A.K.A. Comet).
> This consists of minimal build infrastructure, device tree files, and a
> defconfig based on meta2_defconfig.
>
> This SoC contains a 2-threaded HTP (Meta 2) as the main application
> p
On 24/05/13 17:21, James Hogan wrote:
> If no init_machine callback is provided, call of_platform_populate()
> instead. This allows a board/SoC that only needs to call
> of_platform_populate to omit the callback altogether.
>
> Signed-off-by: James Hogan
> Cc: Grant Likely
> Cc: Rob Herring
> C
On Thu, Jun 13, 2013 at 11:53 AM, Tony Lindgren wrote:
> * Linus Walleij [130613 02:42]:
>> On Thu, Jun 6, 2013 at 9:14 PM, Balaji T K wrote:
>> > + /* 100ms delay required for PBIAS configuration */
>> > + msleep(100);
>> > + if (!vdd && host->pinctrl && host->pbias_off) {
>>
This patchset consists of various miscellaneous arch/metag patches I
intend to apply for v3.11.
The first two improve clock setup, allowing the core clock frequency to
optionally be determined from device tree clock nodes, and to print out
the core and timer clock frequencies during boot. These ar
If the common clock framework is enabled, call of_clk_init(NULL) in
time_init() to register device tree clocks with the clock framework.
After this time_init() calls a new function init_metag_clocks(), which
looks for a clock named "core" in the node compatible with "img,meta"
(usually the root no
Padmavathi Venna wrote:
>
> This patch corrects the base address of pinctrl_3 on Exynos5250
> platform.
>
> Signed-off-by: Padmavathi Venna
> ---
> Changes since V1:
> - Added platform name in the subject line.
>
> arch/arm/boot/dts/exynos5250-pinctrl.dtsi |2 +-
> arch/arm/boot/dts/
1 - 100 of 139 matches
Mail list logo
