On 1/29/2013 1:05 PM, Katepallewar, Mrugesh wrote:
On Mon, Jan 28, 2013 at 21:32:13, Nori, Sekhar wrote:
Hi Mrugesh,
On 1/28/2013 1:17 PM, Mrugesh Katepallewar wrote:
Add RTC DT entries in da850 dts file.
Signed-off-by: Mrugesh Katepallewar mrugesh...@ti.com
---
Applies on top of v3.8-rc4
You forgot spear-devel for this series.
On 29 January 2013 03:28, Arnd Bergmann a...@arndb.de wrote:
This replaces an earlier patch from Viresh Kumar to move
the spear platform over to the generic DMA binding. This
version is now based on the merged multiplatform capable
spear platform,
On 01/28/2013 10:01 PM, Thierry Reding wrote:
On Tue, Jan 22, 2013 at 02:39:53PM +0100, Peter Ujfalusi wrote:
It is expected that board files would have:
static unsigned int bl_levels[] = { 0, 50, 100, 150, 200, 250, };
static struct platform_pwm_backlight_data bl_data = {
.levels =
On 29 January 2013 03:28, Arnd Bergmann a...@arndb.de wrote:
This adds a complete DT binding for the arasan device driver. There is
currently only one user, which is the spear13xx platform, so we don't
actually have to parse all the properties until another user comes in,
but this does use the
On 29.1.2013 01:33, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
Create cmd_dtc_cpp to run the C pre-processor on *.dts file before
passing them to dtc for final compilation. This allows the use of #define
and #include within the .dts file.
Signed-off-by: Stephen Warren
The patch series add DT support on TPS65090 device.
Also remove the suspend/resume implementation as it duplicates with
irq_suspend/irq_resume().
Changes from V1:
- Remove non-required code from the change for checking the match.
- Remove pdata allocation on mfd driver.
- renames some of the
Add device tree support for the TI PMIC TPS65090.
The device can be registered through platform or DT.
Add device tree binding document for this device.
Signed-off-by: Laxman Dewangan ldewan...@nvidia.com
---
Changes from V1:
- Remove non-required code from the change for checking the match.
-
Add DT support for TI PMIC tps65090 regulator driver. The DT of this
device have node regulator and all regulator's node of this device is
added under this node.
The device tree binding document has the required information for
adding this device on DTS file.
Signed-off-by: Laxman Dewangan
When device is get added through DT then irq_base is 0 (zero)
and in this case regmap_irq_chip_get_base() generates warning.
The interrupt of this device get added through irq_domain_add_linear()
when irq_base is 0.
Hence pass the irq domain in place of base_irq when calling
mfd_add_devices().
Hi,
On Mon, Jan 28, 2013 at 8:28 PM, Arnd Bergmann a...@arndb.de wrote:
On Friday 18 January 2013, Padmavathi Venna wrote:
+struct dma_chan *of_dma_pl330_xlate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ int count =
Hi,
On Mon, Jan 28, 2013 at 8:17 PM, Arnd Bergmann a...@arndb.de wrote:
On Friday 18 January 2013, Padmavathi Venna wrote:
diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt
b/Documentation/devicetree/bindings/dma/arm-pl330.txt
index 36e27d5..457a233 100644
---
On Tue, Jan 29, 2013 at 11:50 AM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Fri, Jan 18, 2013 at 05:17:02PM +0530, Padmavathi Venna wrote:
This patch make the dma dev request operation compatible for both
DT and non-DT cases. It takes the all the arguments required for
On Tue, Jan 29, 2013 at 10:49 AM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Fri, Jan 18, 2013 at 05:17:03PM +0530, Padmavathi Venna wrote:
This patch modifies the SPI driver to use generic dma dt bindings
support. This passes all the required arguments to dma dev request
functon
On Tue, Jan 29, 2013 at 12:42 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Fri, Jan 18, 2013 at 05:17:06PM +0530, Padmavathi Venna wrote:
+Samsung SMDK audio complex
This is just for SMDKs with WM8994. I'll apply but please send a
followup patch to clarify this - it'll be a
Hi James,
On Monday 28 January 2013 03:51 PM, James Hogan wrote:
Hi Vineet,
On 24/01/13 10:50, Vineet Gupta wrote:
diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index 4d52a3b..90570f9 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -83,6 +83,9 @@ head-y :=
Hi,
On Mon, Jan 28, 2013 at 7:17 PM, Vinod Koul vinod.k...@intel.com wrote:
On Fri, Jan 18, 2013 at 05:17:09PM +0530, Padmavathi Venna wrote:
Signed-off-by: Padmavathi Venna padm...@samsung.com
---
include/linux/dmaengine.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
On Tue, Jan 22, 2013 at 02:39:56PM +0100, Peter Ujfalusi wrote:
When booting with DT make it possible to use the whole range of the PWM when
controlling the backlight in a same way it is possible when the kernel is
booted in non DT mode.
A new property max-brightness-level can be used to
Hi Vineet,
arm64 also adds dtbs and $(dtb-y) to targets (at least in linux-next). I
think this makes sure that they don't get rebuilt unless they've
actually changed. I've also copied this for metag.
Did you verify that it makes a difference - at least at my end it's not - the
default dtb
On Tue, Jan 29, 2013 at 09:17:04AM +0100, Peter Ujfalusi wrote:
On 01/28/2013 10:01 PM, Thierry Reding wrote:
On Tue, Jan 22, 2013 at 02:39:53PM +0100, Peter Ujfalusi wrote:
It is expected that board files would have:
static unsigned int bl_levels[] = { 0, 50, 100, 150, 200, 250, };
On Tuesday 29 January 2013, Padma Venkat wrote:
of_dma_simple_xlate is just passing the dma channel number to the
filter function. But I also need
to compare against device node as my requested channel can belong to
any of the available dma controller
on SoC. So I implemented a xlate which
On Tuesday 29 January 2013, Viresh Kumar wrote:
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt
b/Documentation/devicetree/bindings/dma/snps-dma.txt
index 5bb3dfb..212d387 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++
On 29 January 2013 16:05, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 29 January 2013, Viresh Kumar wrote:
Shouldn't this be 4? Would be better to mention what fields are these,
right here. I have seen them below though.
Correct. I changed these a couple of times while trying to understand
(putting back the Cc list, I assumed you dropped them accidentally)
On Tuesday 29 January 2013, Andy Shevchenko wrote:
On Mon, 2013-01-28 at 21:58 +, Arnd Bergmann wrote:
- if ((last_dw == dw) (last_bus_id == param))
+ /* both the driver and the device must match */
+if
On Tue, 2013-01-29 at 16:19 +0530, Viresh Kumar wrote:
On 29 January 2013 16:05, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 29 January 2013, Viresh Kumar wrote:
+ /* FIXME: This binding is rather clumsy. Can't we use the
+ request line numbers here instead? */
yes.
On 29 January 2013 16:24, Andy Shevchenko
andriy.shevche...@linux.intel.com wrote:
On Tue, 2013-01-29 at 16:19 +0530, Viresh Kumar wrote:
if (DMA_TO_DEV)
// dest is periph
fargs.cfg_hi = be32_to_cpup(dma_spec-args+0) 11;
else if (DEV_TO_DMA)
// src is periph
On Tue, Jan 29, 2013 at 8:38 AM, Vishwanathrao Badarkhe, Manish
manish...@ti.com wrote:
Currently, I2C driver gets probed before pinctrl driver.
To achieve I2C pin muxing via pinctrl driver before I2C
probe get called, register pinctrl driver in arch_initcall.
Also, add module_exit to
On Tue, Jan 29, 2013 at 02:35:16PM +0530, Laxman Dewangan wrote:
Add DT support for TI PMIC tps65090 regulator driver. The DT of this
device have node regulator and all regulator's node of this device is
added under this node.
There doesn't seem to be any dependency on the rest of the series
On Tue, 2013-01-29 at 16:27 +0530, Viresh Kumar wrote:
On 29 January 2013 16:24, Andy Shevchenko
andriy.shevche...@linux.intel.com wrote:
On Tue, 2013-01-29 at 16:19 +0530, Viresh Kumar wrote:
if (DMA_TO_DEV)
// dest is periph
fargs.cfg_hi = be32_to_cpup(dma_spec-args+0)
On Tue, Jan 29, 2013 at 10:50:23AM +, Arnd Bergmann wrote:
(putting back the Cc list, I assumed you dropped them accidentally)
That'll be why I don't have a copy of Andy's email to reply to.
On Tuesday 29 January 2013, Andy Shevchenko wrote:
On Mon, 2013-01-28 at 21:58 +, Arnd
On 01/29/2013 11:17 AM, Thierry Reding wrote:
On Tue, Jan 29, 2013 at 09:17:04AM +0100, Peter Ujfalusi wrote:
On 01/28/2013 10:01 PM, Thierry Reding wrote:
On Tue, Jan 22, 2013 at 02:39:53PM +0100, Peter Ujfalusi wrote:
It is expected that board files would have:
static unsigned int
On Tue, Jan 22, 2013 at 9:01 PM, Vivek Gautam gautam.vi...@samsung.com wrote:
Changes from v1:
- Putting separate device nodes for usb 2.0 phy and usb 3.0 phy
based on separate driver for samsung usb 3.0 phy and
samsung usb 2.0 phy:
[PATCH v3 0/2] Adding USB 3.0 DRD-phy support for
From: Lad, Prabhakar prabhakar@ti.com
add OF support for the tvp514x driver.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: Guennadi
On Tuesday 29 January 2013, Andy Shevchenko wrote:
+static int pl022_dma_autoprobe(struct pl022 *pl022)
+{
+ struct device *dev = pl022-adev-dev;
+
+ /* automatically configure DMA channels from platform, normally using
DT */
+ pl022-dma_rx_channel =
On Tuesday 29 January 2013, Viresh Kumar wrote:
You forgot spear-devel for this series.
Ok, thanks for adding it.
+ dma-channels = 8;
+ #dma-cells = 3;
Yep, my mistake again. It was correct in v1 of the patch and then
I changed it so it had to be
On 01/24/2013 04:50 AM, Vineet Gupta wrote:
This is minimal infrastructure needed for devicetree work.
It uses an a sample skeleton devicetree - embedded in kernel image -
to print the board, manufacturer by parsing the top-level compatible
string.
As of now we don't need any additional
On Tuesday 29 January 2013, Viresh Kumar wrote:
You can still keep fargs as is and just fill them as:
fargs.cfg_lo = 0;
if (DMA_TO_DEV)
// dest is periph
fargs.cfg_hi = be32_to_cpup(dma_spec-args+0) 11;
else if (DEV_TO_DMA)
// src is periph
Hi Sachin,
On 01/29/2013 05:13 AM, Sachin Kamat wrote:
Added an example for bindings for illustration and clarity.
Cc: devicetree-discuss@lists.ozlabs.org
Cc: Arun Kumar K arun...@samsung.com
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
On Tue, Jan 22, 2013 at 07:29:01PM +, Jason Gunthorpe wrote:
On Thu, Jan 17, 2013 at 04:22:18PM +, Andrew Murray wrote:
In either of those cases, does it make sense to use the MSI support
outside the scope of the PCI infrastructure? That is, would devices
other than PCI devices
On 01/29/2013 05:13 AM, Sachin Kamat wrote:
This patch adds MFC codec support for Exynos4 DT machines.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/boot/dts/exynos4.dtsi |7 +++
arch/arm/mach-exynos/mach-exynos4-dt.c | 17 +
2 files
On 01/29/2013 05:13 AM, Sachin Kamat wrote:
Added MFC codec support to SMDKV310 DT file.
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
arch/arm/boot/dts/exynos4210-smdkv310.dts |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git
On Tuesday 29 January 2013, Russell King - ARM Linux wrote:
On Tuesday 29 January 2013, Andy Shevchenko wrote:
On Mon, 2013-01-28 at 21:58 +, Arnd Bergmann wrote:
- if ((last_dw == dw) (last_bus_id == param))
+ /* both the driver and the device must match */
+if
Hi,
On Tuesday 29 January 2013 04:52 PM, Sascha Hauer wrote:
From: Michael Grzeschik m.grzesc...@pengutronix.de
This adds two little devicetree helper functions for determining the
dr_mode (host, peripheral, otg) and phy_type (utmi, ulpi,...) from
the devicetree.
Signed-off-by: Michael
On Tue, 2013-01-29 at 13:31 +, Arnd Bergmann wrote:
On Tuesday 29 January 2013, Viresh Kumar wrote:
You can still keep fargs as is and just fill them as:
fargs.cfg_lo = 0;
if (DMA_TO_DEV)
// dest is periph
fargs.cfg_hi = be32_to_cpup(dma_spec-args+0) 11;
+err = of_property_read_string(np, phy_type, phy_type);
+if (err 0)
+return USBPHY_INTERFACE_MODE_NA;
Why don't we use a u32 property type for the *phy-type*? IMHO we
should use string property only when the property should be
absolutely unambiguous (e.g., compatible
This is minimal infrastructure needed for devicetree work.
It uses an a sample skeleton devicetree - embedded in kernel image -
to print the board, manufacturer by parsing the top-level compatible
string.
As of now we don't need any additional board specific machine_desc.
TODO: support
On Tuesday 29 January 2013 07:23 PM, Wolfram Sang wrote:
+ err = of_property_read_string(np, phy_type, phy_type);
+ if (err 0)
+ return USBPHY_INTERFACE_MODE_NA;
Why don't we use a u32 property type for the *phy-type*? IMHO we
should use string property only when the
Add device tree files to arch/metag.
Signed-off-by: James Hogan james.ho...@imgtec.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: devicetree-discuss@lists.ozlabs.org
Cc: Sam Ravnborg s...@ravnborg.org
---
v4:
* move dtb directory into dts and use
On Tue, Jan 29, 2013 at 01:44:10PM +, Arnd Bergmann wrote:
Can you give an example for this? We were careful to make sure it
works with platforms that connect a slave to multiple dma engines,
out of which any could be used for a given transfer. In the device
tree binding, you specify all
On Tue, Jan 29, 2013 at 03:45:40PM +0200, Andy Shevchenko wrote:
On Tue, 2013-01-29 at 13:31 +, Arnd Bergmann wrote:
On Tuesday 29 January 2013, Viresh Kumar wrote:
You can still keep fargs as is and just fill them as:
fargs.cfg_lo = 0;
if (DMA_TO_DEV)
//
Hi,
On Tue, Jan 29, 2013 at 07:40:23PM +0530, kishon wrote:
On Tuesday 29 January 2013 07:23 PM, Wolfram Sang wrote:
+ err = of_property_read_string(np, phy_type, phy_type);
+ if (err 0)
+ return USBPHY_INTERFACE_MODE_NA;
Why don't we use a u32 property type for the *phy-type*?
I prefer u32 here, because we have the matching enum. Otherwise we end
up with:
of_property_read_string(...,type);
if (!strcmp(type, ulpi))
foo();
else if (!strcmp(type, utmi))
bar();
else if (!strcmp(type, pipe3))
baz();
else
BUG();
and I don't like
This patch series fixes a bug where of_gpio_named count relied upon a return
value that was no longer returned from of_parse_phandle_with_args and adds the
possibility for of_gpio_named_count to return error values.
In addition, for of_spi_register_master it fixes a bug, adds documentation,
adds
Return value for an empty phandle was -EEXIST before commit 15c9a0ac, that
changed the return value in this case to -ENOENT. However, of_gpio_named_count
relies upon the return value to be -EEXIST and relies upon being able to
distinguish this case from the case of no list at all which also
This lets of_gpio_named_count return an errno on errors by being able to
distinguish between reaching the end of the phandle list and getting some other
error from of_parse_phandle_with_args.
Return error from of_spi_register_master when there is an cs-gpios list for
which gp_gpio_named_count
Using memset does not set an array of integers properly
Signed-off-by: Andreas Larsson andr...@gaisler.com
---
drivers/spi/spi.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 9c2acf1..a4baa0a 100644
--- a/drivers/spi/spi.c
Holes in the cs-gpios DT phandle list is supposed to mark that native
chipselects is to be used. The value returned from of_get_named_gpio_flags in
this case is -EEXIST. By initializing cs_gpios and cs_gpio with -EEXIST, this
and only this errno will indicate to a spi controller driver that a
When using a gpio chip select with a OF_GPIO_ACTIVE_LOW flag, this needs to be
known to the controller driver.
Signed-off-by: Andreas Larsson andr...@gaisler.com
---
Documentation/devicetree/bindings/spi/spi-bus.txt |3 +-
drivers/spi/spi.c | 24
This adds missing kernel-doc entries for cs_gpios in struct spi_master and
cs_gpio in struct spi_device.
Signed-off-by: Andreas Larsson andr...@gaisler.com
---
include/linux/spi/spi.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/spi/spi.h
On 01/29/2013 03:55 PM, Wolfram Sang wrote:
I prefer u32 here, because we have the matching enum. Otherwise we end
up with:
of_property_read_string(...,type);
if (!strcmp(type, ulpi))
foo();
else if (!strcmp(type, utmi))
bar();
else if (!strcmp(type, pipe3))
baz();
On 29 January 2013 19:01, Arnd Bergmann a...@arndb.de wrote:
Ah, good. So I guess the dma-requests property should actually
be 16 then.
yes, even i was checking on that separately :)
Does this mean that an implicit zero request line means memory?
No. 0 is also request line for a peripheral
On Tuesday 29 January 2013, Russell King - ARM Linux wrote:
No, that's not what I mean. I mean the situation we find on Versatile
platforms:
8 3 3
PL080 DMA --/--+--/-- FPGA Mux --/-- {bunch of off-CPU peripherals}
| 5
On Tuesday 29 January 2013, Andy Shevchenko wrote:
On Tue, 2013-01-29 at 13:31 +, Arnd Bergmann wrote:
On Tuesday 29 January 2013, Viresh Kumar wrote:
Ah, good. So I guess the dma-requests property should actually
be 16 then.
Does this mean that an implicit zero request line means
Dear Florian Fainelli,
On Tue, 29 Jan 2013 16:24:04 +0100, Florian Fainelli wrote:
Fix the driver remove callback to unmap the base register address and
not leak this mapping after the driver has been removed.
Signed-off-by: Florian Fainelli flor...@openwrt.org
What about using
Dear Florian Fainelli,
On Tue, 29 Jan 2013 16:24:05 +0100, Florian Fainelli wrote:
This patch renames the base register cookie in the mvmdio drive from
smireg to regs since a subsequent patch is going to use an ioremap()
cookie whose size is larger than a single register of 4 bytes. No
Fix the driver remove callback to unmap the base register address and
not leak this mapping after the driver has been removed.
Signed-off-by: Florian Fainelli flor...@openwrt.org
---
drivers/net/ethernet/marvell/mvmdio.c |3 +++
1 file changed, 3 insertions(+)
diff --git
Hi all,
This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
instead of rolling its own implementation. As a result, all users of this
mv643xx_eth driver are converted to register an orion-mdio platform_device.
The mvmdio driver is also updated to support an interrupt line
This patch enhances the mvmdio to support a SMI error/done interrupt
line which can be used along with a wait queue instead of doing
busy-waiting on the registers. This is a feature which is available in
the mv643xx_eth SMI code and thus reduces again the gap between the two.
Signed-off-by:
This patch renames the base register cookie in the mvmdio drive from
smireg to regs since a subsequent patch is going to use an ioremap()
cookie whose size is larger than a single register of 4 bytes. No
functionnal code change introduced.
Signed-off-by: Florian Fainelli flor...@openwrt.org
---
This patch converts the Marvell MV643XX ethernet driver to use the
Marvell Orion MDIO driver. As a result, PowerPC and ARM platforms
registering the Marvell MV643XX ethernet driver are also updated to
register a Marvell Orion MDIO driver. This driver voluntarily overlaps
with the Marvell Ethernet
This patch changes the Marvell MDIO driver to be registered by using
both Device Tree and platform device methods. The driver voluntarily
does not use devm_ioremap() to share the same error path for Device Tree
and non-Device Tree cases.
Signed-off-by: Florian Fainelli flor...@openwrt.org
---
On 01/28/2013 10:07 AM, Vinod Koul wrote:
On Mon, Jan 28, 2013 at 09:52:00AM -0600, Rob Herring wrote:
On 01/28/2013 09:24 AM, Andy Shevchenko wrote:
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/of/dma.c |2 ++
1 file changed, 2 insertions(+)
You need
On 01/29/2013 04:32 PM, Thomas Petazzoni wrote:
Dear Florian Fainelli,
On Tue, 29 Jan 2013 16:24:04 +0100, Florian Fainelli wrote:
Fix the driver remove callback to unmap the base register address and
not leak this mapping after the driver has been removed.
Signed-off-by: Florian Fainelli
Dear Florian Fainelli,
On Tue, 29 Jan 2013 16:24:06 +0100, Florian Fainelli wrote:
#define MVMDIO_SMI_DATA_SHIFT 0
#define MVMDIO_SMI_PHY_ADDR_SHIFT 16
@@ -36,12 +40,28 @@
#define MVMDIO_SMI_WRITE_OPERATION 0
#define MVMDIO_SMI_READ_VALID
On Tue, Jan 29, 2013 at 02:55:49PM +, Arnd Bergmann wrote:
On Tuesday 29 January 2013, Russell King - ARM Linux wrote:
No, that's not what I mean. I mean the situation we find on Versatile
platforms:
8 3 3
PL080 DMA --/--+--/-- FPGA Mux --/--
Dear Florian Fainelli,
On Tue, 29 Jan 2013 16:24:07 +0100, Florian Fainelli wrote:
This patch changes the Marvell MDIO driver to be registered by using
both Device Tree and platform device methods. The driver voluntarily
does not use devm_ioremap() to share the same error path for Device Tree
Dear Florian Fainelli,
On Tue, 29 Jan 2013 16:24:08 +0100, Florian Fainelli wrote:
This patch converts the Marvell MV643XX ethernet driver to use the
Marvell Orion MDIO driver. As a result, PowerPC and ARM platforms
registering the Marvell MV643XX ethernet driver are also updated to
register
On Tue, Jan 8, 2013 at 5:56 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 01/08/2013 01:16 PM, Sean Paul wrote:
Add a property to the hdmi node so we can specify the HDMI version in
the device tree instead of just defaulting to v1.4 with the existence of
the dt node.
I guess this seems
On Tuesday 29 January 2013, Viresh Kumar wrote:
On 29 January 2013 19:01, Arnd Bergmann a...@arndb.de wrote:
Ah, good. So I guess the dma-requests property should actually
be 16 then.
yes, even i was checking on that separately :)
Actually, I just discovered something odd in the
On 01/29/2013 05:01 PM, Thomas Petazzoni wrote:
Dear Florian Fainelli,
On Tue, 29 Jan 2013 16:24:08 +0100, Florian Fainelli wrote:
This patch converts the Marvell MV643XX ethernet driver to use the
Marvell Orion MDIO driver. As a result, PowerPC and ARM platforms
registering the Marvell
On Tuesday 29 January 2013, Russell King - ARM Linux wrote:
That's a good way to represent it but it fails in a very big way:
You're stuffing N peripherals down to 3 request lines to the DMA
engine, and you may want more than 3 of those peripherals to be
making use of the DMA engine at any one
Dear Florian Fainelli,
On Tue, 29 Jan 2013 17:27:56 +0100, Florian Fainelli wrote:
It looks like I introduced two redundant mvmdio instances as ge01
refers to the ge00 smi bus (the same applies to ge11 and ge10).
Thanks for spotting this.
Ok, good.
If you take a closer look at mv643xx_eth
On 01/28/2013 07:14 PM, Kuninori Morimoto wrote:
Hi Stephen
Thank you for checking path
+Required properties:
+
+- compatible : simple-audio
+- simple-audio,card-name : simple-audio card name
+
+-
On 01/29/2013 03:00 AM, Kuninori Morimoto wrote:
Hi Mark, Stephen
simple-audio,codec {
simple-audio,dev = phandle;
simple-audio,system-clock-frequency = 12288;
};
I would like to ask you before creating v3 patch.
I got some opinions from you.
-
On 01/29/2013 06:44 AM, kishon wrote:
Hi,
On Tuesday 29 January 2013 04:52 PM, Sascha Hauer wrote:
From: Michael Grzeschik m.grzesc...@pengutronix.de
This adds two little devicetree helper functions for determining the
dr_mode (host, peripheral, otg) and phy_type (utmi, ulpi,...) from
the
On 01/29/2013 04:22 AM, Sascha Hauer wrote:
From: Michael Grzeschik m.grzesc...@pengutronix.de
This adds two little devicetree helper functions for determining the
dr_mode (host, peripheral, otg) and phy_type (utmi, ulpi,...) from
the devicetree.
Signed-off-by: Michael Grzeschik
On 01/29/2013 06:11 PM, Stephen Warren wrote:
On 01/29/2013 04:22 AM, Sascha Hauer wrote:
From: Michael Grzeschik m.grzesc...@pengutronix.de
This adds two little devicetree helper functions for determining the
dr_mode (host, peripheral, otg) and phy_type (utmi, ulpi,...) from
the devicetree.
On Tue, Jan 29, 2013 at 04:36:38PM +, Arnd Bergmann wrote:
If the pl080 driver already has code for the mux in it, then it should
handle both of_dma_controller instances in my example. It would
not change anything regarding the binding, which just describes the
way that the hardware is
On Tue, Jan 29, 2013 at 04:24:07PM +0100, Florian Fainelli wrote:
- dev-err_interrupt = irq_of_parse_and_map(pdev-dev.of_node, 0);
+ if (pdev-dev.of_node) {
+ dev-regs = of_iomap(pdev-dev.of_node, 0);
+ if (!dev-regs) {
+
On Tue, Jan 29, 2013 at 04:24:08PM +0100, Florian Fainelli wrote:
This patch converts the Marvell MV643XX ethernet driver to use the
Marvell Orion MDIO driver. As a result, PowerPC and ARM platforms
registering the Marvell MV643XX ethernet driver are also updated to
register a Marvell Orion
On Tue, Jan 29, 2013 at 03:56:20PM -0300, Ezequiel Garcia wrote:
Hi Jason,
On Wed, Jan 23, 2013 at 2:40 PM, Jason Cooper ja...@lakedaemon.net wrote:
On Wed, Jan 23, 2013 at 02:06:12PM -0300, Ezequiel Garcia wrote:
Jason,
On Wed, Jan 23, 2013 at 12:26 PM, Ezequiel Garcia
Hi,
On 01/08/2013 11:56 PM, Stephen Warren wrote:
On 01/08/2013 01:16 PM, Sean Paul wrote:
Add a property to the hdmi node so we can specify the HDMI version in
the device tree instead of just defaulting to v1.4 with the existence of
the dt node.
I guess this seems OK to me if required,
Hi,
On 01/28/2013 09:38 AM, Tomasz Figa wrote:
+
+ mixer: mixer {
+ compatible = samsung,exynos4-mixer;
I'm afraid this compatible property it too generic. Is the video mixer
IP really identical an all the Exynos4 series SoCs ?
It is same in Exynos4210, 4212 and 4412.
Hi,
On 01/28/2013 07:44 AM, Rahul Sharma wrote:
+
+ mixer: mixer {
+ compatible = samsung,exynos4-mixer;
I'm afraid this compatible property it too generic. Is the video mixer IP
really identical an all the Exynos4 series SoCs ?
It is same in Exynos4210, 4212 and 4412.
On Tue, Jan 29, 2013 at 07:14:51PM +0530, kishon wrote:
Hi,
On Tuesday 29 January 2013 04:52 PM, Sascha Hauer wrote:
From: Michael Grzeschik m.grzesc...@pengutronix.de
This adds two little devicetree helper functions for determining the
dr_mode (host, peripheral, otg) and phy_type (utmi,
On Tuesday 29 January 2013, Russell King - ARM Linux wrote:
Well, how it all works in the PL08x driver at present is:
snip
Thanks for the explanations. If I end up implementing the DT support
for pl08x, this will be very helpful. I looked at the git history
for mach-versatile and could not find
Le mardi 29 janvier 2013 19:13:06, Jason Gunthorpe a écrit :
On Tue, Jan 29, 2013 at 04:24:08PM +0100, Florian Fainelli wrote:
This patch converts the Marvell MV643XX ethernet driver to use the
Marvell Orion MDIO driver. As a result, PowerPC and ARM platforms
registering the Marvell MV643XX
Le mardi 29 janvier 2013 18:59:12, Jason Gunthorpe a écrit :
On Tue, Jan 29, 2013 at 04:24:07PM +0100, Florian Fainelli wrote:
- dev-err_interrupt = irq_of_parse_and_map(pdev-dev.of_node, 0);
+ if (pdev-dev.of_node) {
+ dev-regs = of_iomap(pdev-dev.of_node, 0);
+
Hi Jason,
On Wed, Jan 23, 2013 at 2:40 PM, Jason Cooper ja...@lakedaemon.net wrote:
On Wed, Jan 23, 2013 at 02:06:12PM -0300, Ezequiel Garcia wrote:
Jason,
On Wed, Jan 23, 2013 at 12:26 PM, Ezequiel Garcia
ezequiel.gar...@free-electrons.com wrote:
The Armada 370 and Armada XP SoC has an
Hi Rahul,
On 01/28/2013 07:19 AM, Rahul Sharma wrote:
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -289,4 +289,11 @@
interrupts =0 34 0;
};
};
+
+ hdmi {
+ compatible = samsung,exynos4-hdmi14;
On Tue, Jan 29, 2013 at 9:40 PM, Arnd Bergmann a...@arndb.de wrote:
the patches were certainly on the mailing list
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/017818.html
Do you (or Linus) know what happened to the patch series?
Just stalled. My fault probably, and IIRC
1 - 100 of 135 matches
Mail list logo
