From: Lad, Prabhakar prabhakar.cse...@gmail.com
add OF support for the mt9p031 sensor driver.
Alongside this patch sorts the header inclusion alphabetically.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Laurent Pinchart
Hi Sylwester,
Thanks for the review.
On Mon, Apr 29, 2013 at 10:21 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
Hi,
On 04/26/2013 03:18 PM, Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
add OF support for the adv7343 driver.
+++
On Thu, May 02, 2013 at 11:52:34AM +0530, Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
add OF support for the mt9p031 sensor driver.
Alongside this patch sorts the header inclusion alphabetically.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Cc: Hans
Hi Sascha,
Thanks for the quick review.
On Thu, May 2, 2013 at 12:25 PM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Thu, May 02, 2013 at 11:52:34AM +0530, Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
add OF support for the mt9p031 sensor driver.
Alongside this
From: Linus Walleij linus.wall...@linaro.org
This adds support for probing the COH 901 318 DMA controller
and channels from the device tree.
Contains portions of a sketch patch from Arnd Bergmann.
Cc: Arnd Bergmann a...@arndb.de
Acked-by: Vinod Koul vinod.k...@intel.com
Signed-off-by: Linus
From: Linus Walleij linus.wall...@linaro.org
This adds DMA channel assignments to the MMC/SD-controller
and the two UARTs already in the U300 device tree, as we
have now defined a way to obtain DMA channels from the
device tree.
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
From: Linus Walleij linus.wall...@linaro.org
This registers the PL022 PrimeCell from the U300 device
tree. We make a new copy of the platform data for the
device tree boot path, as the old platform data is in an
older file which will be going away.
Signed-off-by: Linus Walleij
-Original Message-
From: Gupta, Pekon
Sent: Thursday, May 02, 2013 2:18 PM
To: Gupta, Pekon; Cousson, Benoit; t...@atomide.com;
li...@arm.linux.org.uk
Cc: Philip, Avinash; linux-o...@vger.kernel.org; devicetree-
disc...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; linux-
This patch implements a basic driver for the I2C host driver found on
the Allwinner A10, A13 and A31 SoCs.
Notable missing feature is 10-bit addressing.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
.../devicetree/bindings/i2c/i2c-sunxi.txt | 19 +
Hi Prabhakar,
Thank you for the patch.
On Thursday 02 May 2013 12:34:25 Prabhakar Lad wrote:
On Thu, May 2, 2013 at 12:25 PM, Sascha Hauer wrote:
On Thu, May 02, 2013 at 11:52:34AM +0530, Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
add OF support for the
On 2 May 2013 16:57, Wolfram Sang w...@the-dreams.de wrote:
Hi,
+ - Samsung GPIO variant (deprecated):
+- gpios: The order of the gpios should be the following: SDA, SCL.
+ The gpio specifier depends on the gpio controller.
Huh? Why should we support a deprecated method with
Hi Laurent,
Thanks for the review.
On Thu, May 2, 2013 at 4:32 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Prabhakar,
Thank you for the patch.
On Thursday 02 May 2013 12:34:25 Prabhakar Lad wrote:
On Thu, May 2, 2013 at 12:25 PM, Sascha Hauer wrote:
On Thu, May 02,
Hi Prabhakar,
On Thursday 02 May 2013 18:48:37 Prabhakar Lad wrote:
On Thu, May 2, 2013 at 4:32 PM, Laurent Pinchart wrote:
On Thursday 02 May 2013 12:34:25 Prabhakar Lad wrote:
On Thu, May 2, 2013 at 12:25 PM, Sascha Hauer wrote:
On Thu, May 02, 2013 at 11:52:34AM +0530, Prabhakar Lad
From: Linus Walleij linus.wall...@linaro.org
This adds device tree support for the U300 timer, by making
the memory base offset and IRQ dynamically assigned, then
optionally looking them up from the device tree.
Since the timer needs to be registered before any platform
devices are created, we
On Thursday 02 May 2013 08:55:18 Sascha Hauer wrote:
+#if defined(CONFIG_OF)
+static struct mt9p031_platform_data *
+ mt9p031_get_pdata(struct i2c_client *client)
+
+{
+ if (client-dev.of_node) {
By inverting the logic here and returning immediately you can safe an
On Thursday 02 May 2013, Linus Walleij wrote:
From: Linus Walleij linus.wall...@linaro.org
This registers the PL022 PrimeCell from the U300 device
tree. We make a new copy of the platform data for the
device tree boot path, as the old platform data is in an
older file which will be going
On Thu, May 2, 2013 at 5:26 PM, Arnd Bergmann a...@arndb.de wrote:
On Thursday 02 May 2013, Linus Walleij wrote:
From: Linus Walleij linus.wall...@linaro.org
This registers the PL022 PrimeCell from the U300 device
tree. We make a new copy of the platform data for the
device tree boot path,
On Tue, Apr 30, 2013 at 02:17:13PM +0200, Guennadi Liakhovetski wrote:
(added Russell to CC, sorry for not including initially)
Hi Vinod
On Tue, 30 Apr 2013, Vinod Koul wrote:
On Tue, Apr 30, 2013 at 09:11:19AM +0200, Guennadi Liakhovetski wrote:
Previously an issue has been
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Add ABB device nodes for OMAP4460 device Data is based on OMAP4460
Technical Reference Manual revision Z (April 2013)
[n...@ti.com: co-developer]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Andrii.Tseglytskyi
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Add ABB device nodes for OMAP443x family of devices. abb_iva is
populated, but disabled as it is not used on current OMAP443x family,
but the node is used on OMAP446x family. Data is based on OMAP443x
Technical Reference Manual revision AN (April
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Add ABB device node for OMAP36xx family of devices. Data is based on
OMAP36XX Technical Reference Manual revision AB (Dec 2012).
[n...@ti.com: co-developer]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Andrii.Tseglytskyi
Adaptive Body Biasing (ABB) modulates transistor bias voltages
dynamically in order to optimize switching speed versus leakage.
Texas Instruments' SoC processors have an on chip LDO subsystem which
is part of the SmartReflex 2 technology and provides support for this
power management technique
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Add ABB device nodes for OMAP5 family of devices. Data is based on
OMAP543x Technical Reference Manual revision U (April 2013).
NOTE: clock node has been disabled in this patch due to the lack of
OMAP5 clock data.
[n...@ti.com: co-developer]
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Adaptive Body Biasing (ABB) modulates transistor bias voltages
dynamically in order to optimize switching speed versus leakage.
Texas Instruments' SmartReflex 2 technology provides support for this
power management technique with Forward Body
On 04/29/2013 04:04 PM, Arnd Bergmann wrote:
On Monday 29 April 2013, Laurent Pinchart wrote:
On Monday 29 April 2013 23:31:30 Tomasz Figa wrote:
Good point. Stephen, would it be a problem to make this a KMS driver
instead? Old fbdev API could be emulated on top of it, until it goes out
of
This patch adds an irqchip driver for the main interrupt controller found
on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, Discovery Innovation).
Corresponding device tree documentation is also added.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Note: This patch
This patch set moves Dove to the recently introduced irqchip driver
for Marvell Orion SoCs. First, init code for timer and mv643xx_eth
is added to prepare legacy non-DT drivers for virtual irqs provided by
irqchip drivers. Then DT enabled boards for Dove are moved to the
orion irqchip driver.
To allow to move to orion irqchip driver, existing legacy devices
have to map their irqs. This patch adds a node for mv643xx_eth and
some init code to map the corresponding irqs. While the device tree
node can stay, the init code will vanish as soon as there is true
device tree support for
To allow to move to orion irqchip driver, existing legacy devices
have to map their irqs. This patch adds a node for orion timer and
some init code to map the corresponding irqs. While the device tree
node can stay, the init code will vanish as soon as there is true
device tree support for orion
With legacy devices mapping their irqs, we can now switch DT enabled
boards to orion irqchip driver.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc:
On 04/22/2013 09:27 AM, Lorenzo Pieralisi wrote:
In order to extend the current cpu nodes bindings to newer CPUs
inclusive of AArch64 and to update support for older ARM CPUs this
patch updates device tree documentation for the cpu nodes bindings.
Since I'm late reviewing this due to vacation,
On 05/02/2013 08:25 PM, Sebastian Hesselbarth wrote:
This patch adds an irqchip driver for the main interrupt controller found
on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, Discovery Innovation).
Corresponding device tree documentation is also added.
Signed-off-by: Sebastian
On Thu, May 2, 2013 at 8:25 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 04/29/2013 04:04 PM, Arnd Bergmann wrote:
On Monday 29 April 2013, Laurent Pinchart wrote:
On Monday 29 April 2013 23:31:30 Tomasz Figa wrote:
Good point. Stephen, would it be a problem to make this a KMS driver
On Thu, May 02, 2013 at 08:33:48PM +0200, Sebastian Hesselbarth wrote:
On 05/02/2013 08:25 PM, Sebastian Hesselbarth wrote:
This patch adds an irqchip driver for the main interrupt controller found
on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, Discovery Innovation).
Corresponding device tree
On 04/29/2013 10:17 AM, Christian Ruppert wrote:
Hello Linus,
On Fri, Apr 26, 2013 at 09:47:16AM +0200, Linus Walleij wrote:
On Thu, Apr 18, 2013 at 11:03 AM, Christian Ruppert
christian.rupp...@abilis.com wrote:
We would like to avoid the use of Linux pin numbers in the device tree.
On 04/18/2013 03:03 AM, Christian Ruppert wrote:
Dear Stephen and Linus,
I am responding to this message because it touches the core issue I was
wondering about when integrating pinctrl with GPIO. I think all
unrelated comments in your other messages are valid and will be
addressed in the
On 05/02/13 20:45, Russell King - ARM Linux wrote:
On Thu, May 02, 2013 at 08:33:48PM +0200, Sebastian Hesselbarth wrote:
On 05/02/2013 08:25 PM, Sebastian Hesselbarth wrote:
This patch adds an irqchip driver for the main interrupt controller found
on Marvell Orion SoCs (Kirkwood, Dove,
On Thu, May 02, 2013 at 08:54:20PM +0200, Sebastian Hesselbarth wrote:
On 05/02/13 20:45, Russell King - ARM Linux wrote:
On Thu, May 02, 2013 at 08:33:48PM +0200, Sebastian Hesselbarth wrote:
On 05/02/2013 08:25 PM, Sebastian Hesselbarth wrote:
This patch adds an irqchip driver for the main
On 05/02/13 20:56, Russell King - ARM Linux wrote:
On Thu, May 02, 2013 at 08:54:20PM +0200, Sebastian Hesselbarth wrote:
On 05/02/13 20:45, Russell King - ARM Linux wrote:
On Thu, May 02, 2013 at 08:33:48PM +0200, Sebastian Hesselbarth wrote:
On 05/02/2013 08:25 PM, Sebastian Hesselbarth
On 05/02/13 20:53, Jason Gunthorpe wrote:
On Thu, May 02, 2013 at 08:25:04PM +0200, Sebastian Hesselbarth wrote:
+
+static void __iomem *orion_irq_base[ORION_MAX_IRQREG];
+static unsigned int orion_irq_regs;
+static struct irq_domain *orion_irq_domain;
+
+asmlinkage void __exception_irq_entry
On Thursday 02 May 2013, Jason Gunthorpe wrote:
+static struct of_device_id orion_irq_dt_ids[] __initconst = {
+ { .compatible = marvell,orion-mpic, .data = orion_of_init },
+ { }
Is there a strong reason to change the compatible string? Looks to me
like either the new driver or
On Thu, May 02, 2013 at 08:25:37PM +0200, Sebastian Hesselbarth wrote:
This patch set moves Dove to the recently introduced irqchip driver
for Marvell Orion SoCs. First, init code for timer and mv643xx_eth
is added to prepare legacy non-DT drivers for virtual irqs provided by
irqchip drivers.
On Thu, May 02, 2013 at 08:25:04PM +0200, Sebastian Hesselbarth wrote:
This patch adds an irqchip driver for the main interrupt controller found
on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, Discovery Innovation).
Corresponding device tree documentation is also added.
Signed-off-by:
On 05/02/2013 09:11 PM, Arnd Bergmann wrote:
On Thursday 02 May 2013, Jason Gunthorpe wrote:
+static struct of_device_id orion_irq_dt_ids[] __initconst = {
+ { .compatible = marvell,orion-mpic, .data = orion_of_init },
+ { }
Is there a strong reason to change the compatible string?
On Thu, May 02, 2013 at 09:05:38PM +0200, Sebastian Hesselbarth wrote:
+static struct of_device_id orion_irq_dt_ids[] __initconst = {
+ { .compatible = marvell,orion-mpic, .data = orion_of_init },
+ { }
Is there a strong reason to change the compatible string? Looks to me
like either
On Thu, May 02, 2013 at 09:34:30PM +0200, Sebastian Hesselbarth wrote:
The compatible string should change if the binding changes in an
incomptible way, and we should try not to change it unless it's
fundamentally flawed.
Well, there is no _fundamental_ change in the binding syntax as it
On 05/02/2013 09:34 PM, Sebastian Hesselbarth wrote:
On 05/02/2013 09:11 PM, Arnd Bergmann wrote:
On Thursday 02 May 2013, Jason Gunthorpe wrote:
+static struct of_device_id orion_irq_dt_ids[] __initconst = {
+ { .compatible = marvell,orion-mpic, .data = orion_of_init },
+ { }
Is there a
On 05/02/2013 09:35 PM, Jason Gunthorpe wrote:
I have kirkwood HW but I haven't had time to make newer kernels run on
it, otherwise I'd test it too :(
I also have kirkwood HW but that will cut me from email as I use it as
relay server ;) Maybe I can turn it into a test bed for a while.
There
On Thu, May 02, 2013 at 09:48:50PM +0200, Sebastian Hesselbarth wrote:
On 05/02/2013 09:35 PM, Jason Gunthorpe wrote:
I have kirkwood HW but I haven't had time to make newer kernels run on
it, otherwise I'd test it too :(
I also have kirkwood HW but that will cut me from email as I use it as
On 05/02/2013 10:02 PM, Andrew Lunn wrote:
On Thu, May 02, 2013 at 09:48:50PM +0200, Sebastian Hesselbarth wrote:
On 05/02/2013 09:35 PM, Jason Gunthorpe wrote:
I have kirkwood HW but I haven't had time to make newer kernels run on
it, otherwise I'd test it too :(
I also have kirkwood HW but
On Thu, 2 May 2013, Vinod Koul wrote:
On Tue, Apr 30, 2013 at 02:17:13PM +0200, Guennadi Liakhovetski wrote:
(added Russell to CC, sorry for not including initially)
Hi Vinod
On Tue, 30 Apr 2013, Vinod Koul wrote:
On Tue, Apr 30, 2013 at 09:11:19AM +0200, Guennadi Liakhovetski
Sebastian,
please do not take the rant below personally. You just happen to
trigger it.
On Thu, 2 May 2013, Sebastian Hesselbarth wrote:
+static void orion_irq_mask(struct irq_data *irqd)
+{
+ unsigned int irq = irqd_to_hwirq(irqd);
+ unsigned int irq_off = irq % 32;
+ int reg
On 05/02/2013 11:34 PM, Thomas Gleixner wrote:
please do not take the rant below personally. You just happen to
trigger it.
Thomas,
it is okay for me - but thanks for the notice! I will comment below.
On Thu, 2 May 2013, Sebastian Hesselbarth wrote:
+static void orion_irq_mask(struct
On Thursday 02 May 2013, Sebastian Hesselbarth wrote:
Just look at the various implementations in drivers/irqchip/ and find
out how similar they are. Moving code to drivers/irqchip/ does not
make an excuse for reestablishing the mess which was addressed by the
generic irq chip
On 05/03/2013 12:09 AM, Arnd Bergmann wrote:
On Thursday 02 May 2013, Sebastian Hesselbarth wrote:
Just look at the various implementations in drivers/irqchip/ and find
out how similar they are. Moving code to drivers/irqchip/ does not
make an excuse for reestablishing the mess which was
This patch set adds an irqchip driver for the main interrupt controller
found on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, Discovery Innovation)
and the corresponding device tree documentation.
It also moves Dove as the first Orion SoC to this irqchip driver.
As legacy non-DT drivers don't
This patch adds an irqchip driver for the main interrupt controller found
on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, Discovery Innovation).
Corresponding device tree documentation is also added.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Note: This patch
To allow to move to orion irqchip driver, existing legacy devices
have to map their irqs. This patch adds init code to map the
corresponding irqs. It will vanish as soon as there is true device tree
support for mv643xx_eth.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
To allow to move to orion irqchip driver, existing legacy devices
have to map their irqs. This patch adds init code to map the
corresponding irqs. It will vanish as soon as there is true device tree
support for orion timer.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
This patch adds required device tree nodes for irqchip conversion
on Dove. The nodes are named and layed out to allow seamless migration
to true DT enabled drivers as soon as they are available.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Changelog:
v1-v2:
- merge DT
With legacy devices mapping their irqs, we can now switch DT enabled
boards to orion irqchip driver.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Changelog:
v1-v2:
- split off DT changes (Suggested by Jason Cooper)
- use irqchip_init (Suggested by Jason Gunthorpe)
Cc:
Hi Dirk,
On Thu, May 02, 2013 at 09:11:19PM +0200, Dirk Eibach wrote:
Hi Guenter,
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index e89fc31..6048593 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1172,6 +1172,38 @@ config
On Fri, May 03, 2013 at 01:48:36AM +0200, Sebastian Hesselbarth wrote:
To allow to move to orion irqchip driver, existing legacy devices
have to map their irqs. This patch adds init code to map the
corresponding irqs. It will vanish as soon as there is true device tree
support for mv643xx_eth.
From: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
This patch adds platform data and DT bindings to allow to overwrite
the stored disabled state for each clock output.
Signed-off-by: Marek Belisko marek.beli...@streamunlimited.com
Signed-off-by: Sebastian Hesselbarth
I think it would be reasonable to have a restriction of only a single
bootfb instance, so one could just use static global variables/funcs to
manage the hand-over.
All this, of course, presumes that nobody else than fbcon is using the
fb. But I think it's also a reasonable restriction that
65 matches
Mail list logo
