1675000),
> TPS65218_INFO(DCDC3, "DCDC3", 90, 340),
> TPS65218_INFO(DCDC4, "DCDC4", 1175000, 340),
Acked-by: Dan Murphy
--
--
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
operly synchronised with writes to DMA coherent memory
> + * (normal memory, uncacheable) and device writes.
> + *
> + * The mb() and wmb() barriers only operate only on the MPU->MA->EMIF
> + * path, as we need to ensure that data is visible to other system
> + * masters prior to writes to those system masters being seen.
> + *
> + * Note: the SRAM path is not synchronised via mb() and wmb().
> + */
> +static void omap4_mb(void)
Sorry for the late response but this throws a warning when CONFIG_ARCH_OMAP4
is not configured.
arch/arm/mach-omap2/omap4-common.c:85:13: warning: 'omap4_mb' defined but not
used [-Wunused-function]
If this was already taken I can just throw a patch up against what ever tree it
is on.
--
--
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Lars
On 09/30/2014 04:29 PM, Lars-Peter Clausen wrote:
> On 09/30/2014 11:18 PM, Dan Murphy wrote:
>> Lars
>>
>> On 09/30/2014 04:03 PM, Lars-Peter Clausen wrote:
>>> On 09/30/2014 06:07 PM, Dan Murphy wrote:
>>>> There may be spi devices that do not req
Lars
On 09/30/2014 04:03 PM, Lars-Peter Clausen wrote:
> On 09/30/2014 06:07 PM, Dan Murphy wrote:
>> There may be spi devices that do not require a
>> register read mask to read the registers.
>>
>> Currently the code sets the read mask based on
>> a non-zero v
Mark
Thanks for the quick review
On 09/30/2014 12:25 PM, Mark Brown wrote:
> On Tue, Sep 30, 2014 at 11:07:00AM -0500, Dan Murphy wrote:
>
>> -if (config->read_flag_mask || config->write_flag_mask) {
>> +if (config->read_flag_mask == REGMAP_NO_REA
On 09/30/2014 12:25 PM, Mark Brown wrote:
> On Tue, Sep 30, 2014 at 11:07:00AM -0500, Dan Murphy wrote:
>
>> -if (config->read_flag_mask || config->write_flag_mask) {
>> +if (config->read_flag_mask == REGMAP_NO_READ_MASK)
>> +map->read_flag_
Mark
Thanks for the review
On 09/30/2014 12:25 PM, Mark Brown wrote:
> On Tue, Sep 30, 2014 at 11:07:00AM -0500, Dan Murphy wrote:
>
>> -if (config->read_flag_mask || config->write_flag_mask) {
>> +if (config->read_flag_mask == REGMAP_NO_READ_MASK)
>>
that the read mask can be zero and separate
out the read flag mask and the write flag mask.
Signed-off-by: Dan Murphy
---
drivers/base/regmap/regmap.c | 11 +++
include/linux/regmap.h |2 ++
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/base/regmap
Add the prcm_resets node to the prcm parent node.
Add the am34xx_resets file to define the
am34xx reset lines that are handled by this reset
framework.
Signed-off-by: Dan Murphy
---
v3 - No changes
arch/arm/boot/dts/am4372.dtsi|7 +
arch/arm/boot/dts/am43xx-resets.dtsi | 52
Describe the TI reset DT entries for TI SoC's.
Signed-off-by: Dan Murphy
---
v3 - Changed Headline no other changes
.../devicetree/bindings/reset/ti,reset.txt | 103
1 file changed, 103 insertions(+)
create mode 100644 Documentation/devicetree/bindings/res
derived from previous work by Rajendra Nayak and Afzal Mohammed.
The code was changed to adopt to the reset core and abstract away the SoC
information.
Signed-off-by: Dan Murphy
---
v3 - Resolved comments from v2. To many to call out here -
https://patchwork.kernel.org/patch/4116941/
drivers
Add the prm_resets node to the prm parent node.
Add the omap54xx_resets file to define the
omap5 reset lines that are handled by this reset
framework.
Signed-off-by: Dan Murphy
---
v3 - No changes
arch/arm/boot/dts/omap5.dtsi |7
arch/arm/boot/dts/omap54xx-resets.dtsi
Add the prcm_resets node to the prcm parent node.
Add the am33xx_resets file to define the
am33xx reset lines that are handled by this reset
framework.
Signed-off-by: Dan Murphy
---
v3 - No changes
arch/arm/boot/dts/am33xx-resets.dtsi | 42 ++
arch/arm/boot
Add the prcm_resets node to the prm parent node.
Add the draxx_resets file to define the
dra7xx reset lines that are handled by this reset
framework.
Signed-off-by: Dan Murphy
---
v3 - No changes
arch/arm/boot/dts/dra7.dtsi |7 +++
arch/arm/boot/dts/dra7xx-resets.dtsi | 82
On 05/06/2014 08:34 AM, Kishon Vijay Abraham I wrote:
> Get reset nodes from dt and use reset framework APIs to reset PCIe.
> This is needed since reset is handled by the SoC.
>
> Cc: Dan Murphy
> Signed-off-by: Kishon Vijay Abraham I
> ---
> Documentation/devicetree/bi
On 05/06/2014 08:34 AM, Kishon Vijay Abraham I wrote:
> Added *resets* and *reset-names* properies for PCIe dt node.
> The documention for this node can be found @ ../bindings/pci/ti-pci.txt.
>
> Cc: Dan Murphy
> Signed-off-by: Kishon Vijay Abraham I
> ---
> arch/arm/boot
Tony
Thanks for the comments
On 05/05/2014 05:01 PM, Tony Lindgren wrote:
> * Dan Murphy [140505 13:10]:
>> +
>> +Required parent properties:
>> +- compatible : Should be one of,
>> +"ti,omap4-prm" for OMAP4 PRM instances
>> +
Felipe
Thanks for the comments
On 05/05/2014 04:33 PM, Felipe Balbi wrote:
> Hi,
>
> On Mon, May 05, 2014 at 03:09:22PM -0500, Dan Murphy wrote:
>> The TI SoC reset controller support utilizes the
>> reset controller framework to give device drivers or
>> function driv
Describe the TI reset DT entries for TI SoC's.
Signed-off-by: Dan Murphy
---
.../devicetree/bindings/reset/ti,reset.txt | 103
1 file changed, 103 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/ti,reset.txt
diff --git a/Document
Add the prm_resets node to the prm parent node.
Add the omap54xx_resets file to define the
omap5 reset lines that are handled by this reset
framework.
Signed-off-by: Dan Murphy
---
arch/arm/boot/dts/omap5.dtsi |7
arch/arm/boot/dts/omap54xx-resets.dtsi | 66
derived from previous work by Rajendra Nayak and Afzal Mohammed.
The code was changed to adopt to the reset core and abstract away the SoC
information.
Signed-off-by: Dan Murphy
---
drivers/reset/Kconfig|1 +
drivers/reset/Makefile |1 +
drivers/reset/ti/Kconfig
Add the prcm_resets node to the prm parent node.
Add the draxx_resets file to define the
dra7xx reset lines that are handled by this reset
framework.
Signed-off-by: Dan Murphy
---
arch/arm/boot/dts/dra7.dtsi |7 +++
arch/arm/boot/dts/dra7xx-resets.dtsi | 82
Add the prcm_resets node to the prcm parent node.
Add the am34xx_resets file to define the
am34xx reset lines that are handled by this reset
framework.
Signed-off-by: Dan Murphy
---
arch/arm/boot/dts/am4372.dtsi|7 +
arch/arm/boot/dts/am43xx-resets.dtsi | 52
All
I have made some big changes to this patchset so I did not put all the
changes in the patches themselves.
In brief
- I removed the object data files for each SoC and moved the data into
the DT. I updated the binding document as well
- The DT implementation creates a parent reset node with
Add the prcm_resets node to the prcm parent node.
Add the am33xx_resets file to define the
am33xx reset lines that are handled by this reset
framework.
Signed-off-by: Dan Murphy
---
arch/arm/boot/dts/am33xx-resets.dtsi | 42 ++
arch/arm/boot/dts/am33xx.dtsi
Tony
On 04/30/2014 05:33 PM, Tony Lindgren wrote:
> * Dan Murphy [140430 11:14]:
>> On 04/30/2014 01:10 PM, Tony Lindgren wrote:
>>> * Dan Murphy [140430 11:00]:
>>>> Tony and Arnd
>>>>
>>>> Thanks for the comments
>>>>
>&
Tony
On 04/30/2014 01:10 PM, Tony Lindgren wrote:
> * Dan Murphy [140430 11:00]:
>> Tony and Arnd
>>
>> Thanks for the comments
>>
>> On 04/29/2014 07:22 PM, Tony Lindgren wrote:
>>> * Arnd Bergmann [140429 13:35]:
>>>> On Tuesday 29 April
Tony and Arnd
Thanks for the comments
On 04/29/2014 07:22 PM, Tony Lindgren wrote:
> * Arnd Bergmann [140429 13:35]:
>> On Tuesday 29 April 2014 15:19:47 Dan Murphy wrote:
>>> + * AM33xx reset index for PRCM Module
>>> + *
>>> + * Copyright 2014 Texas I
Philipp and Arnd
Thank you for the comments
On 04/30/2014 03:20 AM, Philipp Zabel wrote:
> Hi Dan,
>
> Am Dienstag, den 29.04.2014, 15:19 -0500 schrieb Dan Murphy:
>> The TI SoC reset controller support utilizes the
>> reset controller framework to give device drivers or
Add the prcm_resets node to the prcm parent node.
Add the dt-bindings header to the DT file
Signed-off-by: Dan Murphy
---
arch/arm/boot/dts/am4372.dtsi|6 ++
include/dt-bindings/reset/ti,am437x-resets.h | 19 +++
2 files changed, 25 insertions
Add the reset register data for the omap5 SoC.
Signed-off-by: Dan Murphy
---
drivers/reset/ti/Makefile |1 +
drivers/reset/ti/reset-ti-data.h |2 ++
drivers/reset/ti/reset-ti-omap5.c | 61 +
drivers/reset/ti/reset-ti.c |3 ++
4
This is a RFC on the TI reset adoption to the Reset framework.
The patchset was derived from work from Rajendra Nayak and Afzal Mohammed
who have had similar code offerings. One of the major differences here
is the SoC data has been broken out so that the data and code are independent.
There is
Add the prm_resets node to the prm parent node.
Add the dt-bindings header to the DT file
Signed-off-by: Dan Murphy
---
arch/arm/boot/dts/omap5.dtsi|6 ++
include/dt-bindings/reset/ti,omap5-resets.h | 22 ++
2 files changed, 28 insertions(+)
create
Add the reset register data for the am43xx SoC.
Signed-off-by: Dan Murphy
---
drivers/reset/ti/Makefile |1 +
drivers/reset/ti/reset-ti-am43xx.c | 43
drivers/reset/ti/reset-ti-data.h |1 +
3 files changed, 45 insertions(+)
create mode
Add the reset register data for the dra7xx SoC.
Include the dt-bindings header to properly index
the right reset node.
Signed-off-by: Dan Murphy
---
drivers/reset/ti/Makefile |1 +
drivers/reset/ti/reset-ti-data.h |1 +
drivers/reset/ti/reset-ti-dra7xx.c | 61
Add the prcm_resets node to the prcm parent node.
Add the dt-bindings header to the DT file
Signed-off-by: Dan Murphy
---
arch/arm/boot/dts/am33xx.dtsi|6 ++
include/dt-bindings/reset/ti,am33xx-resets.h | 18 ++
2 files changed, 24 insertions(+)
create
Add the reset register data for the am335 SoC.
Signed-off-by: Dan Murphy
---
drivers/reset/ti/Makefile |1 +
drivers/reset/ti/reset-ti-am33xx.c | 37
drivers/reset/ti/reset-ti-data.h |1 +
drivers/reset/ti/reset-ti.c|3 +++
4
derived from previous work by Rajendra Nayak and Afzal Mohammed.
The code was changed to adopt to the reset core and abstract away the SoC
information.
Signed-off-by: Dan Murphy
---
drivers/reset/Kconfig|1 +
drivers/reset/Makefile |1 +
drivers/reset/ti/Kconfig
Call the reset init API to initialize the
reset framework and data for the related SoC.
Signed-off-by: Dan Murphy
---
arch/arm/mach-omap2/prm_common.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index b4c4ab9
Describe the TI reset DT entries for TI SoC's.
Signed-off-by: Dan Murphy
---
.../devicetree/bindings/reset/ti,reset.txt | 34
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/ti,reset.txt
diff --git a/Document
Add the prcm_resets node to the prm parent node.
Add the dt-bindings header to the DT file
Signed-off-by: Dan Murphy
---
arch/arm/boot/dts/dra7.dtsi|6 ++
include/dt-bindings/reset/ti,dra7-resets.h | 22 ++
2 files changed, 28 insertions(+)
create
omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
--
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Set the alias for ethernet0 and ethernet1 so that uBoot
can set the MAC address appropriately.
Currently uBoot cannot find the alias and there for does not set the
MAC address.
Signed-off-by: Dan Murphy
---
arch/arm/boot/dts/am33xx.dtsi |2 ++
1 file changed, 2 insertions(+)
diff --git a
contains features for software development and test.
Why do we want to send this upstream?
What is the advantage to having this supported?
I don't believe we need to add another community board. We have a SDP
and Panda.
Dan
--
------
Dan Murphy
Sricharan
Thanks for sending this up in the series.
On 06/05/2013 01:46 AM, Sricharan R wrote:
> From: Dan Murphy
>
> Add support for blue LED 1 off of GPIO 153.
> Make the LED a heartbeat LED
> Configure the MUX for GPIO output.
>
> Cc: Dan Murphy
> Signed-off-by: Da
Update the dt property ti,audpwron-gpio to use the
gpio macro definition for GPIO_ACTIVE_HIGH.
Signed-off-by: Dan Murphy
---
arch/arm/boot/dts/omap4-panda-common.dtsi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy
---
v10 - Update gpio
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy
---
v9 - Removed
On 05/31/2013 10:05 AM, Javier Martinez Canillas wrote:
> On Fri, May 31, 2013 at 4:48 PM, Dan Murphy wrote:
>> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
>> are different.
>>
>> A1-A3 = gpio_wk7
>> ES = gpio_110
>>
>> The
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy
---
v8 - Rebase to
Hi
On 05/31/2013 09:06 AM, Benoit Cousson wrote:
> Hi Dan,
>
> On 05/29/2013 01:20 PM, Dan Murphy wrote:
>> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
>> are different.
>>
>> A1-A3 = gpio_wk7clean
>> ES = gpio_110
>>
>&g
t; - omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
> + if (_dev->scheme == OMAP_I2C_SCHEME_0)
> + omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
> + else
> + omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR,
> +OMAP_I2C_IP_V
Fix spelling in my own comments
On 05/30/2013 03:31 PM, Dan Murphy wrote:
> On 05/30/2013 03:14 PM, Ruchika Kharwar wrote:
>> This patch adds an optional parameter "dr_mode" to the dwc3 core device node.
>> In the case the compile flag for the DWC3 controller is set to
_mode, "drd") == 0)
> + mode = DWC3_MODE_DRD;
> + else {
> + dev_err(dev, "invalid dr_mode property
> value\n");
> + goto err0;
This should be err1 since core init is called p
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy
---
v7 - Update
On 05/17/2013 11:17 AM, Dan Murphy wrote:
> On 05/17/2013 11:15 AM, Nishanth Menon wrote:
>> On 11:02-20130517, Dan Murphy wrote:
>>> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
>>> are different.
>>>
>>> A1-A3 = gpio_wk7
&g
On 05/17/2013 11:15 AM, Nishanth Menon wrote:
> On 11:02-20130517, Dan Murphy wrote:
>> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
>> are different.
>>
>> A1-A3 = gpio_wk7
>> ES = gpio_110
>>
>> There is no change to LED
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy
---
Changes in this
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy
---
v5 - Provide
On 05/16/2013 01:18 PM, Nishanth Menon wrote:
> On Thu, May 16, 2013 at 10:35 AM, Dan Murphy wrote:
>> I am not sure you really want to do this.
>> If I make the pinctrl part of the led structure then the only way the
>> gpio_wk7 on a1-a3 to be configured is when
>> t
On 05/15/2013 12:05 PM, Nishanth Menon wrote:
> On 11:46-20130515, Dan Murphy wrote:
>> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
>> are different.
>>
>> A1-A3 = gpio_wk7
>> ES = gpio_110
>>
>> There is no change to LED
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy
---
arch/arm/boot
NM
On 05/15/2013 12:29 AM, Nishanth Menon wrote:
> $subject - add a space?
> s/ARM:dts:omap4-panda:Update/ARM: dts: omap4-panda: Update/ ?
Will fix.
> On 09:17-20130514, Dan Murphy wrote:
>> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
>> are d
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy
---
arch/arm/boot
Tony
On 05/08/2013 06:47 PM, Tony Lindgren wrote:
> * Dan Murphy [130418 11:35]:
>> On 04/18/2013 04:30 AM, Vincent Stehlé wrote:
>>> On 04/17/2013 10:16 PM, Dan Murphy wrote:
>>>> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
>>>&g
On 04/18/2013 04:30 AM, Vincent Stehlé wrote:
On 04/17/2013 10:16 PM, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
(..)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy
---
arch/arm/boot
On 04/17/2013 02:18 PM, Jon Hunter wrote:
On 04/17/2013 02:09 PM, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
Abstract away the pinmux and the LED definitions for the two boards.
Just a heads-up but you should base this upon
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
Abstract away the pinmux and the LED definitions for the two boards.
Signed-off-by: Dan Murphy
---
arch/arm/boot/dts/omap4-panda-es.dts | 33 +
arch/arm/boot/dts/omap4
The LED GPIOs between the 4430 (a1-a4) and 4460 (es) panda boards
are different. This patch abstracts the LED definitions into the
respective board files.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo
interfaces with a test file.
Signed-off-by: Dan Murphy
---
arch/arm/mach-omap2/mux.c | 73 +
arch/arm/mach-omap2/mux.h | 23 ++
2 files changed, 77 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach
71 matches
Mail list logo
