On Thu, 2012-09-13 at 15:36 +0900, Alex Courbot wrote:
> On Thursday 13 September 2012 14:22:57 Tomi Valkeinen wrote:
>
> > However, I fear these board specific things may be quite a bit anything,
> > so it may well be pwm, gpios and regulators are not enough for them. For
> > example, there coul
On Thu, 2012-09-13 at 15:23 +0900, Alex Courbot wrote:
> DT support is actually the main point of power sequences, as outside of the
> DT
> we can always work the old way and use callbacks. If we were to remove DT
> support, I am not sure this work would still be worth being merged.
Ah, I gues
On Thu, 2012-09-13 at 15:23 +0900, Alex Courbot wrote:
> On Thursday 13 September 2012 13:50:47 Tomi Valkeinen wrote:
> > I want to reiterate my opinion that I think power sequences in DT data
> > is the wrong way to go. Powering sequences are device specific issues
> > and should be handled in th
On Thursday 13 September 2012 14:25:53 Mark Brown wrote:
> On Thu, Sep 13, 2012 at 03:23:06PM +0900, Alex Courbot wrote:
> > I understand the logic behind handling powering sequences in the device
> > driver, but as we discussed for some classes of devices this might just
> > not
> > scale. I don't
On Thursday 13 September 2012 14:22:57 Tomi Valkeinen wrote:
> * PGP Signed by an unknown key
>
> On Thu, 2012-09-13 at 15:08 +0900, Alex Courbot wrote:
>
> > On Thursday 13 September 2012 13:45:39 Tomi Valkeinen wrote:
> >
> > > > Old Signed by an unknown key
> > >
> > >
> > > On Wed, 2012-09
On Thu, Sep 13, 2012 at 03:23:06PM +0900, Alex Courbot wrote:
> I understand the logic behind handling powering sequences in the device
> driver, but as we discussed for some classes of devices this might just not
> scale. I don't know how many different panels (each with different powering
It
On Wed, Sep 12, 2012 at 22:51:55, Cousson, Benoit wrote:
> + Paul
>
> Hi Anil,
>
> On 08/31/2012 11:37 AM, AnilKumar Ch wrote:
> > Add DT OPP table for AM33XX family of devices. This data is
> > decoded by OF with of_init_opp_table() helper function.
> >
> > Also adds cpu0 supply name to the cor
On Thu, 2012-09-13 at 15:08 +0900, Alex Courbot wrote:
> On Thursday 13 September 2012 13:45:39 Tomi Valkeinen wrote:
> > * PGP Signed by an unknown key
> >
> > On Wed, 2012-09-12 at 18:57 +0900, Alexandre Courbot wrote:
> >
> > > Some device drivers (panel backlights especially) need to follow p
On Thursday 13 September 2012 13:50:47 Tomi Valkeinen wrote:
> * PGP Signed by an unknown key
>
> On Wed, 2012-09-12 at 18:57 +0900, Alexandre Courbot wrote:
>
> > New revision of the power sequences, taking as usual the feedback that
> > was
> > kindly provided about the last version.
> >
> > I
On Thursday 13 September 2012 13:45:39 Tomi Valkeinen wrote:
> * PGP Signed by an unknown key
>
> On Wed, 2012-09-12 at 18:57 +0900, Alexandre Courbot wrote:
>
> > Some device drivers (panel backlights especially) need to follow precise
> > sequences for powering on and off, involving gpios, regu
On Thursday 13 September 2012 06:07:13 Stephen Warren wrote:
> On 09/12/2012 03:57 AM, Alexandre Courbot wrote:
> > Some device drivers (panel backlights especially) need to follow precise
> > sequences for powering on and off, involving gpios, regulators, PWMs
> > with a precise powering order and
On Thursday 13 September 2012 05:33:56 Anton Vorontsov wrote:
> On Wed, Sep 12, 2012 at 03:27:04PM -0600, Stephen Warren wrote:
>
> > On 09/12/2012 03:57 AM, Alexandre Courbot wrote:
> >
> > > New revision of the power sequences, taking as usual the feedback that
> > > was
> > > kindly provided a
On Wed, 2012-09-12 at 18:57 +0900, Alexandre Courbot wrote:
> New revision of the power sequences, taking as usual the feedback that was
> kindly provided about the last version.
>
> I think now is a good time to discuss integrating this and to start looking
> for
> a maintainer who would be will
On Wed, 2012-09-12 at 18:57 +0900, Alexandre Courbot wrote:
> Some device drivers (panel backlights especially) need to follow precise
> sequences for powering on and off, involving gpios, regulators, PWMs
> with a precise powering order and delays to respect between each steps.
> These sequences a
On 09/12/2012 01:14 PM, Stefano Stabellini wrote:
> On Wed, 12 Sep 2012, Stefano Stabellini wrote:
>> On Tue, 28 Aug 2012, Rob Herring wrote:
>>> You should look at ePAPR 1.1 which defines hypervisor related bindings.
>>> While it is a PPC doc, we should reuse or extend what makes sense.
>>>
>>> Se
To allow mailbox driver to function with device tree.
Tested in OMAP4 and OMAP3. OMAP2 untested.
Patch: arm/dts: OMAP2+: Add mailbox nodes, was Acked by Benoit
however it seems it wasn't picked up, so resend.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69121.html
Patch: OMAP: mail
Add nodes for mailbox DT, to interface with hwmods.
Signed-off-by: Omar Ramirez Luna
Acked-by: Benoit Cousson
---
arch/arm/boot/dts/omap2.dtsi |5 +
arch/arm/boot/dts/omap3.dtsi |5 +
arch/arm/boot/dts/omap4.dtsi |5 +
3 files changed, 15 insertions(+)
diff --git a/arch
Adapt driver to use DT if provided.
Signed-off-by: Omar Ramirez Luna
---
.../devicetree/bindings/arm/omap/mailbox.txt |9 +
arch/arm/mach-omap2/devices.c |3 +++
arch/arm/mach-omap2/mailbox.c | 12
3 files changed, 24
To allow mailbox driver to function with device tree.
Tested in OMAP4 and OMAP3. OMAP2 untested.
Patch: arm/dts: OMAP2+: Add mailbox nodes, was Acked by Benoit
however it seems it wasn't picked up, so resend.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69121.html
Patch: OMAP: mail
On 09/12/2012 03:17 PM, Guennadi Liakhovetski wrote:
> On Wed, 12 Sep 2012, Stephen Warren wrote:
>
>> On 09/12/2012 01:28 PM, Guennadi Liakhovetski wrote:
>>> Hi Stephen
>>>
>>> On Wed, 12 Sep 2012, Stephen Warren wrote:
>>>
On 09/11/2012 09:51 AM, Guennadi Liakhovetski wrote:
> This pat
On 09/12/2012 03:57 AM, Alexandre Courbot wrote:
> Make use of the power sequences specified in the device tree or platform
> data to control how the backlight is powered on and off.
>
> Signed-off-by: Alexandre Courbot
Reviewed-by: Stephen Warren
__
On 09/12/2012 03:57 AM, Alexandre Courbot wrote:
> Some device drivers (panel backlights especially) need to follow precise
> sequences for powering on and off, involving gpios, regulators, PWMs
> with a precise powering order and delays to respect between each steps.
> These sequences are board-sp
On Wed, Sep 12, 2012 at 03:27:04PM -0600, Stephen Warren wrote:
> On 09/12/2012 03:57 AM, Alexandre Courbot wrote:
> > New revision of the power sequences, taking as usual the feedback that was
> > kindly provided about the last version.
> >
> > I think now is a good time to discuss integrating th
On 09/12/2012 03:57 AM, Alexandre Courbot wrote:
> New revision of the power sequences, taking as usual the feedback that was
> kindly provided about the last version.
>
> I think now is a good time to discuss integrating this and to start looking
> for
> a maintainer who would be willing to merg
On 09/12/2012 03:57 AM, Alexandre Courbot wrote:
> Signed-off-by: Alexandre Courbot
Both patches 3 and 4 in the series,
Acked-by: Stephen Warren
I will take those patches into the Tegra tree when (hopefully rather
than if) patches 1 and 2 are accepted.
__
On Wed, 12 Sep 2012, Stephen Warren wrote:
> On 09/12/2012 01:28 PM, Guennadi Liakhovetski wrote:
> > Hi Stephen
> >
> > On Wed, 12 Sep 2012, Stephen Warren wrote:
> >
> >> On 09/11/2012 09:51 AM, Guennadi Liakhovetski wrote:
> >>> This patch adds a document, describing common V4L2 device tree b
On 09/12/2012 12:54 AM, Thomas Petazzoni wrote:
> Le Tue, 11 Sep 2012 16:17:13 -0600,
> Stephen Warren a écrit :
>
>>
>> +static struct mvebu_mpp_mode dove_mpp_modes[] = {
>> +MPP_MODE(0,
>> +MPP_FUNCTION(0x00, "gpio", NULL),
>> +MPP_FUNCTION(0x02, "uart2", "rts"),
>>
On 09/12/2012 12:56 AM, Thomas Petazzoni wrote:
> Le Tue, 11 Sep 2012 16:23:19 -0600,
> Stephen Warren a écrit :
>
>> On 09/10/2012 02:39 AM, Sebastian Hesselbarth wrote:
>>> From: Thomas Petazzoni
>>>
>>> The Armada 370 and XP SoCs have configurable muxing for a certain
>>> number of their pins
On 09/12/2012 01:28 PM, Guennadi Liakhovetski wrote:
> Hi Stephen
>
> On Wed, 12 Sep 2012, Stephen Warren wrote:
>
>> On 09/11/2012 09:51 AM, Guennadi Liakhovetski wrote:
>>> This patch adds a document, describing common V4L2 device tree bindings.
>>>
>>> Co-authored-by: Sylwester Nawrocki
>>> S
Just a few small comments...
On 09/12/2012 03:34 PM, Arun Kumar K wrote:
This patch adds device tree entry for MFC v6 in the Exynos5
SoC. Makes the required changes in the clock files and adds
MFC to the DT device list.
Signed-off-by: Naveen Krishna Chatradhi
Signed-off-by: Arun Kumar K
---
..
Add nodes for iommu DT, to interface with hwmods.
Cc: Grant Likely
Cc: Rob Herring
Cc: Benoit Cousson
Signed-off-by: Omar Ramirez Luna
---
arch/arm/boot/dts/omap3.dtsi | 12 +++-
arch/arm/boot/dts/omap4.dtsi | 17 -
2 files changed, 27 insertions(+), 2 deletions(-)
Adapt driver to use DT if provided.
Signed-off-by: Omar Ramirez Luna
---
.../devicetree/bindings/arm/omap/iommu.txt | 10 +++
arch/arm/mach-omap2/omap-iommu.c |4 ++
drivers/iommu/omap-iommu.c | 65 +++-
3 files changed, 7
These functions save and restore registers irrespectively of their
read or write permissions, this ends up in registers being saved
that can't be restored because of read only attributes. OTOH, so
far only 3 of them need to be saved.
In future GP_REG (which is present only on OMAP4 ipu) needs to b
Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations and sysconfig
handling.
Dues to reset sequence, pm_runtime_put_sync must be used, to avoid
possible operations with the module under reset.
Signed-off-by: Omar Ramirez Luna
---
arch/arm/
Save and restore context during pm runtime transitions.
For now, the previous API for this purpose will trigger
pm runtime functions, and will be left as exported symbol
for compatibility with it's only user.
Signed-off-by: Omar Ramirez Luna
---
drivers/iommu/omap-iommu.c | 29 +++
Use hwmod data and device attributes to build and register an
omap device for iommu driver.
- Update the naming convention in isp module.
- Remove unneeded check for number of resources, as this is now
handled by omap_device and prevents driver from loading.
- Now unused, remove platform dev
Add mmu hwmod data for ipu and dsp.
Cc: Benoit Cousson
Signed-off-by: Omar Ramirez Luna
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 136 +++-
1 file changed, 134 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach
Add mmu hwmod data for iva and isp.
Due to compatibility an ifdef CONFIG_OMAP_IOMMU_IVA2 needs to be
propagated (previously on iommu resource info) to hwmod data in OMAP3,
so users of iommu and tidspbridge can avoid issues of two modules
managing mmu data/irqs/resets; this until tidspbridge can be
If included without IOMMU_API being selected it will break
compilation:
arch/arm/plat-omap/include/plat/iommu.h:
In function 'dev_to_omap_iommu':
arch/arm/plat-omap/include/plat/iommu.h:148:
error: 'struct dev_archdata' has no member named 'iommu'
This will be seen when hwmod incl
These patches are needed for remoteproc to work on OMAP4.
Introduced iommu hwmod support for OMAP3 (iva, isp) and
OMAP4 (ipu, dsp), along with the corresponding runtime PM
and routines to deassert reset lines, enable/disable clocks
and configure sysc registers.
Due to compatibility an ifdef needs
Hi Stephen
On Wed, 12 Sep 2012, Stephen Warren wrote:
> On 09/11/2012 09:51 AM, Guennadi Liakhovetski wrote:
> > This patch adds a document, describing common V4L2 device tree bindings.
> >
> > Co-authored-by: Sylwester Nawrocki
> > Signed-off-by: Guennadi Liakhovetski
>
> Overall, I think th
On 09/11/2012 09:51 AM, Guennadi Liakhovetski wrote:
> This patch adds a document, describing common V4L2 device tree bindings.
>
> Co-authored-by: Sylwester Nawrocki
> Signed-off-by: Guennadi Liakhovetski
Overall, I think this looks pretty reasonable, so:
Acked-by: Stephen Warren
Just a cou
On 09/12/2012 02:57 AM, Daniel Mack wrote:
> On 10.09.2012 21:40, Stephen Warren wrote:
>> On 09/10/2012 09:03 AM, Daniel Mack wrote:
>>> Add DT bindings for the gpio-regulator driver and some documentation on
>>> how to use it.
...
>>> +++ b/Documentation/devicetree/bindings/regulator/gpio-regulat
On Wed, 12 Sep 2012, Stefano Stabellini wrote:
> On Tue, 28 Aug 2012, Rob Herring wrote:
> > You should look at ePAPR 1.1 which defines hypervisor related bindings.
> > While it is a PPC doc, we should reuse or extend what makes sense.
> >
> > See section 7.5:
> >
> > https://www.power.org/resour
+ Paul
Hi Anil,
On 08/31/2012 11:37 AM, AnilKumar Ch wrote:
> Add DT OPP table for AM33XX family of devices. This data is
> decoded by OF with of_init_opp_table() helper function.
>
> Also adds cpu0 supply name to the corresponding dts files.
> cpu0-supply name is used by cpufreq-cpu0 driver to
On Tue, 28 Aug 2012, Rob Herring wrote:
> On 08/16/2012 10:35 AM, Stefano Stabellini wrote:
> > Add a doc to describe the Xen ARM device tree bindings
> >
> > Signed-off-by: Stefano Stabellini
> > CC: devicetree-discuss@lists.ozlabs.org
> > CC: David Vrabel
> > ---
> > Documentation/devicetree/
Hi Jon,
On 09/11/2012 06:01 PM, Jon Hunter wrote:
> Add a minimal dts for original OMAP3430/3530 version of the Beagle board. This
> version of the Beagle board has 256MB of DDR and features the same TWL4030
> power management IC (PMIC) as the Beagle board XM.
>
> Given that the Beagle and Beagle
On Thu, Sep 6, 2012 at 4:19 PM, Arnd Bergmann wrote:
> On Thursday 06 September 2012, Linus Walleij wrote:
>> On Thu, Sep 6, 2012 at 3:20 PM, Rob Herring wrote:
>> > [Me]
>> >> I can of course skip the aliases and go for the timer nodes
>> >> I want directly, but that isn't any helpful for people
On 09/06/2012 05:10 PM, Stephen Warren wrote:
> From: Gyungoh Yoo
>
> The MAX8907 is an I2C-based power-management IC containing voltage
> regulators, a reset controller, a real-time clock, and a touch-screen
> controller.
Samuel,
This patch as-is won't compile due to the mfd_add_devices() API
On Wed, Sep 05, 2012 at 12:28:58PM -0700, Stephen Boyd wrote:
> diff --git a/arch/arm/boot/dts/msm8960-cdp.dts
> b/arch/arm/boot/dts/msm8960-cdp.dts
> + intc: interrupt-controller@0200 {
> + timer@0200a004 {
> + timer@0200a024 {
Same here. Again, I'll fix these when I pull the
On Wed, Sep 12, 2012 at 6:01 PM, Thomas Petazzoni
wrote:
> See for example
> http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf,
> which is the hardware datasheet for the 88F6281 Marvell SoC (Kirkwood
> family). Table 26 on page 53 of the PDF is a good example. I
On Wed, Sep 05, 2012 at 12:28:58PM -0700, Stephen Boyd wrote:
> diff --git a/arch/arm/boot/dts/msm8960-cdp.dts
> b/arch/arm/boot/dts/msm8960-cdp.dts
> +
> + intc: interrupt-controller@0200 {
> + compatible = "qcom,msm-qgic2";
> + interrupt-controller;
> +
On Wed, Sep 05, 2012 at 12:28:53PM -0700, Stephen Boyd wrote:
> diff --git a/Documentation/devicetree/bindings/arm/msm/timer.txt
> b/Documentation/devicetree/bindings/arm/msm/timer.txt
> + timer@0200a004 {
> + compatible = "qcom,msm-gpt", "qcom,msm-timer";
> + i
On Wed, Sep 12, 2012 at 8:54 AM, Thomas Petazzoni
wrote:
> This data structure really reflects what the datasheet says. Typically,
> for SoCs where each pin is independently muxable (AT91, i.MX23/28,
> Marvell, and probably many more), the datasheet has a big array, with
> one line per pin, and t
Signed-off-by: Gregory CLEMENT
---
arch/arm/boot/dts/armada-370-db.dts |4
arch/arm/boot/dts/armada-370-xp.dtsi |1 +
drivers/clocksource/time-armada-370-xp.c | 11 ++-
3 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.d
Signed-off-by: Gregory CLEMENT
---
arch/arm/boot/dts/armada-370.dtsi | 13 ++
arch/arm/boot/dts/armada-xp.dtsi| 49 +++
arch/arm/mach-mvebu/Kconfig |5
arch/arm/mach-mvebu/armada-370-xp.c |9 ++-
arch/arm/mach-mvebu/common
Add Armada 370/XP specific clocks: core clocks and CPU clocks.
The CPU clocks are only for Armada XP which can be SMP.
The core clocks are clocks which have their rate set during reset. The
code was written with the other SoCs of the mvebu family in
mind. Adding them should be pretty straight for
Hello,
The purpose of this patch set is to add support for clock framework
for Armada 370 and Armada XP SoCs. All the support is done under the
directory drivers/clk/mvebu/ as the support for other mvebu SoCs was
in mind during the writing of the code.
Two kinds of clocks are added:
- The CPU cl
On 09/12/2012 12:45 PM, Praveen Paneri wrote:
> This driver uses usb_phy interface to interact with s3c-hsotg. Supports
> phy_init and phy_shutdown functions to enable/disable phy. Tested with
> smdk6410 and smdkv310. More SoCs can be brought under later.
>
> Signed-off-by: Praveen Paneri
> Acked
Hi Wolfram,
Le 09/12/2012 12:16 PM, Wolfram Sang a écrit :
On Wed, Sep 12, 2012 at 10:03:59AM +0200, Nicolas Ferre wrote:
On 09/12/2012 08:42 AM, ludovic.desroc...@atmel.com :
From: Ludovic Desroches
Hi,
This set of patches is based on Nikolaus at91_i2c driver.
Changes:
v3:
- only put m
Signed-off-by: Alexandre Courbot
---
arch/arm/boot/dts/tegra20-ventana.dts | 59 ++-
1 file changed, 58 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts
b/arch/arm/boot/dts/tegra20-ventana.dts
index 3e5952f..4ca3ceb 100644
--- a/arc
This is necessary to reference the PWM in board device trees.
Signed-off-by: Alexandre Courbot
---
arch/arm/boot/dts/tegra20.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 405d167..67a6cd9 100644
---
Some device drivers (panel backlights especially) need to follow precise
sequences for powering on and off, involving gpios, regulators, PWMs
with a precise powering order and delays to respect between each steps.
These sequences are board-specific, and do not belong to a particular
driver - theref
Make use of the power sequences specified in the device tree or platform
data to control how the backlight is powered on and off.
Signed-off-by: Alexandre Courbot
---
.../bindings/video/backlight/pwm-backlight.txt | 65 +++-
drivers/video/backlight/Kconfig| 1 +
dr
New revision of the power sequences, taking as usual the feedback that was
kindly provided about the last version.
I think now is a good time to discuss integrating this and to start looking for
a maintainer who would be willing to merge this into his/her tree (I am
especially thinking about the p
Hi Stephen,
On 10.09.2012 21:40, Stephen Warren wrote:
> On 09/10/2012 09:03 AM, Daniel Mack wrote:
>> Add DT bindings for the gpio-regulator driver and some documentation on
>> how to use it.
>
>> +++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
>> @@ -0,0 +1,58 @@
>> +Device
On 09/12/2012 08:42 AM, ludovic.desroc...@atmel.com :
> From: Ludovic Desroches
>
> Hi,
>
> This set of patches is based on Nikolaus at91_i2c driver.
>
> Changes:
> v3:
> - only put multi-drive lines in the if...else statement (suggested
> by Warner Losh)
Hi Wolfram,
As said by Ludovic, t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/12/2012 08:14 AM, Felipe Balbi :
> Hi,
>
> On Tue, Sep 11, 2012 at 02:20:19PM +0200, Nicolas Ferre wrote:
>> On 09/11/2012 02:07 PM, Fabio Porcedda :
>>> Don't fail the initialization check for the platform_data if
>>> there is avaiable an assoc
68 matches
Mail list logo
