On Tuesday 18 June 2013, Ezequiel Garcia wrote:
+Required properties:
+
+- compatible: Should be set to one of the following:
+ marvell,armada370-mbus
+ marvell,armadaxp-mbus
+
+- reg:Device's register space.
+ Two entries are
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
+ devbus-bootcs {
+ compatible = marvell,mvebu-devbus;
+ reg = 0x0001 0x10400 0x8;
+ ranges = 0 MBUS_ID(0x01, 0x2f) 0 0x;
+
This patch adds Device Tree support to the shdma driver. No special DT
properties are used, only standard DMA DT bindings are implemented. Since
shdma controllers reside on SoCs, their configuration is SoC-specific and
shall be passed to the driver from the SoC platform data, using the
auxdata
Perhaps a more specific subject.
On 06/17/2013 12:24 PM, Alexander Shiyan wrote:
Patch adds of_get_next_child and of_get_next_available_child
stubs for non-OF builds.
Signed-off-by: Alexander Shiyan shc_w...@mail.ru
---
What changed for v2?
include/linux/of.h | 16 ++--
1
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
+ ranges =
+ 0x8200 0 0x40x0001 0x4 0
0x2000
+ 0x8200 0 0x80x0001 0x8 0
0x2000
+
Perhaps a more specific subject.
I can just specify stub function names in the subject.
Is this enough?
On 06/17/2013 12:24 PM, Alexander Shiyan wrote:
Patch adds of_get_next_child and of_get_next_available_child
stubs for non-OF builds.
Signed-off-by: Alexander Shiyan
On Tuesday 18 June 2013, Guennadi Liakhovetski wrote:
This patch adds Device Tree support to the shdma driver. No special DT
properties are used, only standard DMA DT bindings are implemented. Since
shdma controllers reside on SoCs, their configuration is SoC-specific and
shall be passed to
Dear Arnd Bergmann,
On Tue, 18 Jun 2013 18:14:33 +0200, Arnd Bergmann wrote:
Using 0x0002 as a placeholder for the pcie translation is definitely
better than 0x as you had before, but let me ask again in case
you missed it the last time (and sorry if I missed the answer):
Why
On 06/18/13 14:09, Rahul Sharma wrote:
Hi Mr. Kukjin,
Kindly consider the following patches for review and integration.
(+ Mike)
Rahul, basically, looks good to me but I'm waiting for Mike's ack on
this series...
regards,
Rahul Sharma.
On Fri, Jun 14, 2013 at 3:39 PM, Arun Kumar
Dear Arnd Bergmann,
On Tue, 18 Jun 2013 18:29:35 +0200, Arnd Bergmann wrote:
To clarify my earlier comment, I think it would be nicer to write this as
ranges =
0x8200 0 0x40x0001 0x4 0
0x2000
On 06/11/13 15:29, Sachin Kamat wrote:
This series is based on for-next branch of Kukjin's tree.
Tested on Origen board.
Changes since v1:
* Split LCD patch into LCD and PWM as suggested by Tomasz Figa.
* Added all PWM output nodes to pinctrl dtsi file.
Sachin Kamat (3):
ARM: dts:
Dear Arnd Bergmann,
On Tue, 18 Jun 2013 19:18:58 +0200, Arnd Bergmann wrote:
ranges =
0x8200 0 0x40x0001 0x4
0 0x2000
0x8200 0 0x80x0001 0x8
0
On Tuesday 18 June 2013, Thomas Petazzoni wrote:
Dear Arnd Bergmann,
On Tue, 18 Jun 2013 18:14:33 +0200, Arnd Bergmann wrote:
Using 0x0002 as a placeholder for the pcie translation is definitely
better than 0x as you had before, but let me ask again in case
you missed it
On Tuesday 18 June 2013, Thomas Petazzoni wrote:
To clarify my earlier comment, I think it would be nicer to write this as
ranges =
0x8200 0 0x40x0001 0x4 0
0x2000
0x8200 0
On Tue, Jun 18, 2013 at 08:25:30AM -0300, Ezequiel Garcia wrote:
The address decoding window to access the BootROM should not be
allocated programatically, but instead declared in the device tree.
Signed-off-by: Ezequiel Garcia ezequiel.gar...@free-electrons.com
On Tue, Jun 18, 2013 at 08:25:28AM -0300, Ezequiel Garcia wrote:
+
+IIAA
+
+Where:
+ -- I = Marvell defined target ID for programmable windows
+ -- A = Marvell defined target attributes for programmable windows
I thought we agreed to something like:
SIAA
Where 'S' is the
On Tuesday 18 June 2013, Thomas Petazzoni wrote:
On Tue, 18 Jun 2013 19:18:58 +0200, Arnd Bergmann wrote:
ranges =
0x8200 0 0x40x0001
0x4 0 0x2000
0x8200 0 0x8
On Tue, Jun 18, 2013 at 07:44:48PM +0200, Lubomir Rintel wrote:
This adds a driver for watchdog timer hardware present on Broadcom BCM2835
SoC,
used in Raspberry Pi and Roku 2 devices.
Signed-off-by: Lubomir Rintel lkund...@v3.sk
Tested-by: Stephen Warren swar...@wwwdotorg.org
Cc: Stephen
On 06/18/2013 07:46 PM, Jason Gunthorpe wrote:
On Tue, Jun 18, 2013 at 08:25:28AM -0300, Ezequiel Garcia wrote:
+
+IIAA
+
+Where:
+ -- I = Marvell defined target ID for programmable windows
+ -- A = Marvell defined target attributes for programmable windows
I thought we agreed to
On Tuesday 18 June 2013, Sebastian Hesselbarth wrote:
On 06/18/2013 07:46 PM, Jason Gunthorpe wrote:
On Tue, Jun 18, 2013 at 08:25:28AM -0300, Ezequiel Garcia wrote:
+
+IIAA
+
+Where:
+ -- I = Marvell defined target ID for programmable windows
+ -- A = Marvell defined target
On 06/18/2013 11:28 AM, Heiko Stübner wrote:
Am Dienstag, 18. Juni 2013, 17:38:35 schrieb Heiko Stübner:
Hi Pavel,
Am Dienstag, 18. Juni 2013, 17:02:44 schrieb Pavel Machek:
Hi!
The following 2 patches will eliminate the need for the patch in John
Stultz's tree. If there is to be merge of
Am Dienstag, 18. Juni 2013, 17:38:35 schrieb Heiko Stübner:
Hi Pavel,
Am Dienstag, 18. Juni 2013, 17:02:44 schrieb Pavel Machek:
Hi!
The following 2 patches will eliminate the need for the patch in John
Stultz's tree. If there is to be merge of the 2 trees, then the
patch:
On Tue, Jun 18, 2013 at 04:11:16PM +0100, Russell King - ARM Linux wrote:
On Tue, Jun 18, 2013 at 05:02:49PM +0200, Linus Walleij wrote:
Nowadays I would do the above with regmap_update_bits().
Mutual exclusion for read-modify-write of individual bits in a
register is one of those cases
On 06/18/2013 08:39 PM, Arnd Bergmann wrote:
On Tuesday 18 June 2013, Sebastian Hesselbarth wrote:
Also allows you to have up to 40b offset, which might be important
with LPAE enabled.
Not with the current generation I think, since the mbus windows are
32 bit only, but it would avoid having
On Tue, Jun 18, 2013 at 08:44:30PM +0200, Sebastian Hesselbarth wrote:
On 06/18/2013 08:39 PM, Arnd Bergmann wrote:
On Tuesday 18 June 2013, Sebastian Hesselbarth wrote:
Also allows you to have up to 40b offset, which might be important
with LPAE enabled.
Not with the current generation I
On 06/18/2013 08:47 PM, Jason Gunthorpe wrote:
On Tue, Jun 18, 2013 at 08:44:30PM +0200, Sebastian Hesselbarth wrote:
Yeah, I also recall Thomas or Gregory mention a 32b limitation in
remap windows. But we don't need to waste addresses here
And even if SIAA is a concern because there may
On Tue, Jun 18, 2013 at 08:22:08PM +0200, Arnd Bergmann wrote:
Arnd, we've discussed this at length with you while getting the PCIe
driver merged, and we've explained this to you numerous times. Could
you please understand that any of your proposal that suggests writing
down
On Tue, Jun 18, 2013 at 08:59:03PM +0200, Sebastian Hesselbarth wrote:
S = 0 means 4 bit I, 8 bit A
S = F means special
S = 1 could mean 16 bit I, etc , etc
S 0x8 == 0x0 means 7b target
S 0x8 == 0x8 means 7b special ?
No need, special == mbus driver defined. There is no target ID.
The
On 06/18/2013 09:10 PM, Jason Gunthorpe wrote:
On Tue, Jun 18, 2013 at 08:59:03PM +0200, Sebastian Hesselbarth wrote:
S = 0 means 4 bit I, 8 bit A
S = F means special
S = 1 could mean 16 bit I, etc , etc
S 0x8 == 0x0 means 7b target
S 0x8 == 0x8 means 7b special ?
No need, special ==
On 06/18/2013 05:31 PM, Ezequiel Garcia wrote:
Although the internal register window size is 1 MiB, the previous
ranges translation for the internal register space had a size of
0x400. This was done to allow the crypto and nand node to access
the corresponding 'sram' and 'nand' decoding
On Tue, Jun 18, 2013 at 11:39:06AM -0600, Jason Gunthorpe wrote:
On Tue, Jun 18, 2013 at 08:25:30AM -0300, Ezequiel Garcia wrote:
The address decoding window to access the BootROM should not be
allocated programatically, but instead declared in the device tree.
Signed-off-by: Ezequiel
On Tue, Jun 18, 2013 at 09:42:48PM +0200, Sebastian Hesselbarth wrote:
On 06/18/2013 05:31 PM, Ezequiel Garcia wrote:
Although the internal register window size is 1 MiB, the previous
ranges translation for the internal register space had a size of
0x400. This was done to allow the
On Tue, Jun 18, 2013 at 04:43:31PM -0300, Ezequiel Garcia wrote:
I think some kind of test is needed here. As I understand it the SMP
startup uses a trampoline in the boot rom and the boot rom *must* be
mapped to 0xfff0 ?
Yes, that's my understanding as well, but I will do some
On Tue, Jun 18, 2013 at 05:02:42PM -0300, Ezequiel Garcia wrote:
Having the kernel enforce that the DT node is present and at the right
location, I think, is helpful for the bootloader folks to ensure they
write correct DTs.
Granted. But then I wonder... why do we bother to put the BootROM
On Tue, Jun 18, 2013 at 11:40 AM, John Stultz john.stu...@linaro.org wrote:
On 06/18/2013 11:28 AM, Heiko Stübner wrote:
Am Dienstag, 18. Juni 2013, 17:38:35 schrieb Heiko Stübner:
Hi Pavel,
Am Dienstag, 18. Juni 2013, 17:02:44 schrieb Pavel Machek:
Hi!
The following 2 patches will
On Tue, Jun 18, 2013 at 02:10:21PM -0600, Jason Gunthorpe wrote:
On Tue, Jun 18, 2013 at 05:02:42PM -0300, Ezequiel Garcia wrote:
Having the kernel enforce that the DT node is present and at the right
location, I think, is helpful for the bootloader folks to ensure they
write correct
From: Dinh Nguyen dingu...@altera.com
Add bindings for SD/MMC for SOCFPGA.
Add syscon to the altr,sys-mgr binding.
Signed-off-by: Dinh Nguyen dingu...@altera.com
Reviewed-by: Pavel Machek pa...@denx.de
CC: Arnd Bergmann a...@arndb.de
CC: Olof Johansson o...@lixom.net
Cc: Pavel Machek
Hi Sebastian,
You loose +1 internet points for dropping me from Cc ;-)
On Tue, Jun 18, 2013 at 09:27:28PM +0200, Sebastian Hesselbarth wrote:
On 06/18/2013 09:10 PM, Jason Gunthorpe wrote:
The forms could be:
0IAA
FK00
- K=0 - internal regs
- K=1 - PCI-E
On Tue, Jun 18, 2013 at 05:49:11PM -0300, Ezequiel Garcia wrote:
Hi Sebastian,
You loose +1 internet points for dropping me from Cc ;-)
On Tue, Jun 18, 2013 at 09:27:28PM +0200, Sebastian Hesselbarth wrote:
On 06/18/2013 09:10 PM, Jason Gunthorpe wrote:
The forms could be:
On Tue, Jun 18, 2013 at 02:55:22PM -0600, Jason Gunthorpe wrote:
On Tue, Jun 18, 2013 at 05:49:11PM -0300, Ezequiel Garcia wrote:
Hi Sebastian,
You loose +1 internet points for dropping me from Cc ;-)
On Tue, Jun 18, 2013 at 09:27:28PM +0200, Sebastian Hesselbarth wrote:
On
On Tuesday 18 June 2013, Jason Gunthorpe wrote:
On Tue, Jun 18, 2013 at 08:22:08PM +0200, Arnd Bergmann wrote:
Arnd, we've discussed this at length with you while getting the PCIe
driver merged, and we've explained this to you numerous times. Could
you please understand that any
Hi Kishon,
I've noticed there is a little inconsistency between the code and
documentation.
On 06/13/2013 10:43 AM, Kishon Vijay Abraham I wrote:
+3. Creating the PHY
+
+The PHY driver should create the PHY in order for other peripheral controllers
+to make use of it. The PHY framework
Arnd,
On Tue, Jun 18, 2013 at 06:14:33PM +0200, Arnd Bergmann wrote:
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
+Required properties:
+
+- compatible: Should be set to one of the following:
+marvell,armada370-mbus
+marvell,armadaxp-mbus
+
+- reg:
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
+
+ ranges =
+ 0x8200 0 0x40x0001 0x4 0
0x2000
+ 0x8200 0 0x80x0001 0x8 0
0x2000
+
On Tue, Jun 18, 2013 at 11:20:07PM +0200, Arnd Bergmann wrote:
On Tuesday 18 June 2013, Jason Gunthorpe wrote:
On Tue, Jun 18, 2013 at 08:22:08PM +0200, Arnd Bergmann wrote:
Arnd, we've discussed this at length with you while getting the PCIe
driver merged, and we've explained
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
On Tue, Jun 18, 2013 at 06:14:33PM +0200, Arnd Bergmann wrote:
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
+Required properties:
+
+- compatible: Should be set to one of the following:
+ marvell,armada370-mbus
+
On Tue, Jun 18, 2013 at 06:16:26PM +0200, Arnd Bergmann wrote:
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
+ devbus-bootcs {
+ compatible = marvell,mvebu-devbus;
+ reg = 0x0001 0x10400 0x8;
+ ranges
On Tue, Jun 18, 2013 at 07:09:29PM -0300, Ezequiel Garcia wrote:
On Tue, Jun 18, 2013 at 06:16:26PM +0200, Arnd Bergmann wrote:
On Tuesday 18 June 2013, Ezequiel Garcia wrote:
+ devbus-bootcs {
+ compatible = marvell,mvebu-devbus;
+
On Tuesday, June 18, 2013 10:57 PM, Arnd Bergmann wrote:
On Tuesday 18 June 2013, Jingoo Han wrote:
On Monday, June 17, 2013 9:45 PM, Arnd Bergmann wrote:
On Monday 17 June 2013 18:45:52 Jingoo Han wrote:
On Friday, June 14, 2013 9:54 PM, Arnd Bergmann wrote:
[.]
I will
Hi Eduardo,
On 06/18/2013 03:16 PM, Eduardo Valentin wrote:
Benoit
On 07-06-2013 16:46, Eduardo Valentin wrote:
Include bandgap devices for OMAP4460 devices.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc:
Hi Roger,
On 06/18/2013 11:04 AM, Roger Quadros wrote:
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Fix to return -ENOMEM in the kmem_cache_create() error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/infiniband/hw/ehca/ehca_main.c | 1 +
1 file changed, 1
+ mike
On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma rahul.sha...@samsung.com wrote:
Add clock changes for hdmi subsystem for exynos5250 SoC. These
include addition of new clocks like mout_hdmi and smmu_tv, associating
ID to clk_hdmiphy and some essential corrections.
This set is based on
On 06/17/2013 10:20 AM, Tushar Behera wrote:
On 06/11/2013 12:23 AM, Tomasz Figa wrote:
On Monday 10 of June 2013 09:13:11 Tushar Behera wrote:
On 06/08/2013 05:20 PM, Tomasz Figa wrote:
On Thursday 06 of June 2013 16:52:28 Tushar Behera wrote:
[ ... ]
MUX_A(mout_core, mout_core,
Hi Rahul,
Code part looks good to me but IMHO, binding document for exynos_mixer
is also fixed like following because compitable string
samsung,exynos5420-mixer is added with this patch.
Required properties:
- compatible: value should be:
1) samsung,exynos4210-mixer
2)
From: Kishon Vijay Abraham I kis...@ti.com
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 instead of
extcon_get_extcon_dev()).
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Chanwoo Choi
Sure Seung-Woo,
I will update binding document along with this patch.
regards,
Rahul Sharma.
On Wed, Jun 19, 2013 at 10:54 AM, 김승우 sw0312@samsung.com wrote:
Hi Rahul,
Code part looks good to me but IMHO, binding document for exynos_mixer
is also fixed like following because compitable
Hi Rahul,
This patch looks good to me.
On 2013년 06월 18일 21:49, Rahul Sharma wrote:
Modified code for calculating hdmi IP register values from drm timing
values. The modification is based on the inputs from hw team and specifically
proposed for 1440x576i and 1440x480i. But same changes holds
Hi Rahul,
It looks good, at least, to me.
Best Regards,
- Seung-Woo Kim
On 2013년 06월 18일 21:49, Rahul Sharma wrote:
This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was
To disable spurious interrupts, that get triggered on certain hardware, the
irqpin driver masks them on the parent interrupt controller. To specify
such broken devices a .control_parent parameter can be provided in the
platform data. In the DT case we need a property, to do the same.
On 6/7/2013 5:02 PM, Mugunthan V N wrote:
Add pinmux DT nodes to CPSW for the following AM335x boards
* AM335x Beaglebone
* AM335x EVM
* AM335x EVMsk
default state contains the pinmux required for active mode and
sleep mode contains pinmux reset values for energy saving.
Mugunthan V N (3):
101 - 161 of 161 matches
Mail list logo
