On Wed, Aug 22, 2012 at 11:21:03PM -0600, Stephen Warren wrote:
> On 08/22/2012 01:18 AM, Dong Aisheng wrote:
> > Signed-off-by: Dong Aisheng
>
> > diff --git a/drivers/regulator/anatop-regulator.c
> > b/drivers/regulator/anatop-regulator.c
>
> > @@ -109,7 +110,11 @@ static int __devinit anatop
On Wed, Aug 22, 2012 at 11:16:33PM -0600, Stephen Warren wrote:
> On 08/22/2012 04:57 AM, Dong Aisheng wrote:
> > On Wed, Aug 22, 2012 at 04:29:41PM +0800, Zhao Richard-B20223 wrote:
> >> On Wed, Aug 22, 2012 at 03:18:42PM +0800, Dong Aisheng wrote:
> >>> Add regmap based imx syscon driver.
> >>> T
On 08/22/2012 01:18 AM, Dong Aisheng wrote:
> Signed-off-by: Dong Aisheng
> diff --git a/drivers/regulator/anatop-regulator.c
> b/drivers/regulator/anatop-regulator.c
> @@ -109,7 +110,11 @@ static int __devinit anatop_regulator_probe(struct
> platform_device *pdev)
> rdesc->ops = &anatop
On 08/22/2012 04:57 AM, Dong Aisheng wrote:
> On Wed, Aug 22, 2012 at 04:29:41PM +0800, Zhao Richard-B20223 wrote:
>> On Wed, Aug 22, 2012 at 03:18:42PM +0800, Dong Aisheng wrote:
>>> Add regmap based imx syscon driver.
>>> This is usually used for access misc bits in registers which does not belon
On 08/22/2012 08:36 AM, Shawn Guo wrote:
> For those SoCs that have hundreds of clock outputs, their clock
> DT bindings could reasonably define #clock-cells as 1 and require
> the client device specify the index of the clock it consumes in the
> cell of its "clocks" phandle.
>
> Add a generic of_
On 08/22/2012 07:08 PM, Matt Sealey wrote:
> Ugh. Okay my blood sugar was super low. Can I just condense that into
> I agree with Russell and the binding makes no sense once it gets past
> the simple definition described in the binding?
I can't speak for Russell, but I think his issue is addressed
On Wed, Aug 22, 2012 at 03:10:00PM -0700, Subodh Nijsure wrote:
> Right now that is what I am doing in my code, requesting GPIOs in
> UART drivers and setting up the direction. I just wanted to make
> sure there wasn't way to setup pin direction using pinmux itself.
>
No, there is no way for pinct
On Wed, Aug 22, 2012 at 10:37 AM, Subodh Nijsure wrote:
>
> For a MX28 based hardware I am working with I need to use AUART4
>
> I need to configure this AUART4 as uart only when necessary and at all other
> times pins associated with AUART4 need to be configured as inputs.
>
> I am using followin
Ugh. Okay my blood sugar was super low. Can I just condense that into
I agree with Russell and the binding makes no sense once it gets past
the simple definition described in the binding?
If we take the pinctrl mess as an example, all the DT serves to do is
define an SoC-specific or family-specifi
David Daney wrote:
>>
>> The problem is that we don't normally consider the FPGA node to be a bus,
>> so its child nodes won't get probed. That's why I have this:
>>
>
> That would seem to be a mistake/error.
Maybe I'm not explaining myself well. A node that has children will not
automatically
On 08/22/2012 04:10 PM, Subodh Nijsure wrote:
> On 08/22/2012 12:52 PM, Stephen Warren wrote:
>> On 08/22/2012 09:37 AM, Subodh Nijsure wrote:
>>> For a MX28 based hardware I am working with I need to use AUART4
>>>
>>> I need to configure this AUART4 as uart only when necessary and at all
>>> othe
On 08/22/2012 03:38 PM, Timur Tabi wrote:
David Daney wrote:
I wonder if *fpga is really a good name for this. It is a general
purpose multiplexer with a memory mapped control register. I would call
it something like mdio-mux-mmioreg.
At one point, I thought of using mdio-mux-bitbang, but -
On Tue, Aug 21, 2012 at 7:53 AM, Rob Herring wrote:
>
>> How do you explain duplicating the clock names in the array AND in the
>> device node as NOT being bloated?
>
> Read the clock binding doc. Names are optional and the 2 names are not
> the same. One is the name of the output on the CCM and o
David Daney wrote:
> I wonder if *fpga is really a good name for this. It is a general
> purpose multiplexer with a memory mapped control register. I would call
> it something like mdio-mux-mmioreg.
At one point, I thought of using mdio-mux-bitbang, but -mmioreg is better.
Thanks.
>> +- mdi
On 08/22/2012 02:45 PM, Timur Tabi wrote:
An FPGA controls which sub-bus is connected to the master MDIO bus. The
FPGA must be memory-mapped and contain only 8-bit registers (which keeps
things simple).
Tested on a Freescale P5020DS board which uses the "PIXIS" FPGA attached
to the localbus.
S
On 08/22/2012 12:52 PM, Stephen Warren wrote:
On 08/22/2012 09:37 AM, Subodh Nijsure wrote:
For a MX28 based hardware I am working with I need to use AUART4
I need to configure this AUART4 as uart only when necessary and at all
other times pins associated with AUART4 need to be configured as in
On Wed, 2012-08-22 at 15:07 -0600, Stephen Warren wrote:
> On 08/21/2012 02:47 PM, Tony Prisk wrote:
> > Bindings for gpio, interrupt controller, power management controller,
> > timer, realtime clock, serial uart, ehci and uhci controllers and
> > framebuffer controllers used on the arch-vt8500 pl
On 08/21/2012 02:47 PM, Tony Prisk wrote:
> Bindings for gpio, interrupt controller, power management controller,
> timer, realtime clock, serial uart, ehci and uhci controllers and
> framebuffer controllers used on the arch-vt8500 platform.
>
> Framebuffer binding also specifies a 'display' node
* Mark Brown [120822 12:12]:
> On Thu, Aug 16, 2012 at 04:41:01PM +0300, Peter Ujfalusi wrote:
> > On OMAP2430 all McBSP ports have 128 word long buffer, enable the use of
> > the FIFO for the audio stack.
> >
> > Signed-off-by: Peter Ujfalusi
> > Acked-by: Jarkko Nikula
>
> I applied this - T
On 08/22/2012 02:22 AM, Sebastian Hesselbarth wrote:
> This commits adds the necessary device tree information to define the
> compatible property for the pinctrl driver instance of Armada 370 SoC.
> diff --git a/arch/arm/boot/dts/armada-370.dtsi
> b/arch/arm/boot/dts/armada-370.dtsi
> +
> +
On 08/22/2012 02:22 AM, Sebastian Hesselbarth wrote:
> This commits adds the necessary device tree information to define the
> compatible property for the pinctrl driver instance of Armada XP SoCs.
>
> Until now, the device tree representation considered the Armada XP as
> a single SoC. But in fac
On 08/22/2012 02:22 AM, Sebastian Hesselbarth wrote:
> This patch adds a pinctrl driver core for Marvell SoCs plus DT
> binding documentation. This core driver will be used by SoC family
> specific drivers, i.e. Armada XP, Armada 370, Dove, Kirkwood, aso.
> +++ b/Documentation/devicetree/bindings/
On 08/22/2012 09:37 AM, Subodh Nijsure wrote:
>
> For a MX28 based hardware I am working with I need to use AUART4
>
> I need to configure this AUART4 as uart only when necessary and at all
> other times pins associated with AUART4 need to be configured as inputs.
Out of curiosity, why?
BTW, yo
On Wed, Aug 22, 2012 at 12:19:59PM -0700, Guenter Roeck wrote:
> On Wed, Aug 22, 2012 at 07:32:30PM +0100, Mark Brown wrote:
> > This feels like the wrong thing to do here: given that the user needs to
> > explicitly ask for the device to be instantiated we really ought to be
> > one the right bus
On Tue, Aug 21, 2012 at 05:33:56PM +0300, Peter Ujfalusi wrote:
> To reflect the final devicetree node structure of McBSPs.
>
> Signed-off-by: Peter Ujfalusi
Applied, thanks.
> the initial OMAP McBSP DT structure was not able to describe the IP (and it's
> versions) correctly.
> The main issue
On Thu, Aug 16, 2012 at 04:41:08PM +0300, Peter Ujfalusi wrote:
> Device tree support for McBSP modules on OMAP2+ SoC.
Applied, thanks.
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
On Thu, Aug 16, 2012 at 04:41:07PM +0300, Peter Ujfalusi wrote:
> Only create the devices in a legacy way if we do not have the DT data.
Applied, thanks.
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discus
On Thu, Aug 16, 2012 at 04:41:06PM +0300, Peter Ujfalusi wrote:
> We can use the has_ccr flag to replace the cpu_is_omap* checks.
> This provides future proof implementation and we do not need to update the
> code if new OMAP revision starts to use the McBSP driver.
Applied, thanks.
signature.as
On Thu, Aug 16, 2012 at 04:41:05PM +0300, Peter Ujfalusi wrote:
> NUM_LINKS is no longer in use by the code.
Applied, thanks.
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://l
On Thu, Aug 16, 2012 at 04:41:04PM +0300, Peter Ujfalusi wrote:
> Remove the feature to configure the CLKR/FSR mux on McBSP port with 6pin
> configuration.
> When moving to devicetree these callback can no longer be used in a clean
> way anymore.
Applied but this didn't quite apply cleanly, please
On Thu, Aug 16, 2012 at 04:41:03PM +0300, Peter Ujfalusi wrote:
> The muxing is done at board level, no need to do it in the ASoC machine
> driver.
Applied, thanks.
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
device
On Thu, Aug 16, 2012 at 04:41:02PM +0300, Peter Ujfalusi wrote:
> am3517evm board uses McBSP1 for audio with 4pin configuration.
> The CLKR/FSR signals need to be connected to CLKX/FSX pin of the SoC in
> this case.
Applied, thanks.
signature.asc
Description: Digital signature
__
On Thu, Aug 16, 2012 at 04:41:01PM +0300, Peter Ujfalusi wrote:
> On OMAP2430 all McBSP ports have 128 word long buffer, enable the use of
> the FIFO for the audio stack.
>
> Signed-off-by: Peter Ujfalusi
> Acked-by: Jarkko Nikula
I applied this - Tony, from the thread it seemed you were OK eve
On Thu, Aug 16, 2012 at 04:41:00PM +0300, Peter Ujfalusi wrote:
> Move the McBSP CLKS re-parenting code to ASoC driver from
> arch/arm/mach-omap2.
> The call fort the re-parenting has been already limited to OMAP2+ SoC in
> the ASoC driver. There is no longer need to have callback function for it.
From: David Daney
Commit 002176db (misc: at25: Parse dt settings) added device tree
bindings the differ significantly in style from the I2C EEPROM
bindings and don't seem well vetted. Here I deprecate (but still
support) the "at25,*" properties, and add what I hope is a better
alternative. Thes
From: David Daney
With this patch we get automatic driver loading and binding for device
tree specified hardware typologies. Also recognize "st,m95256"
devices as being compatible with the driver.
Signed-off-by: David Daney
---
drivers/misc/eeprom/at25.c | 8 +++-
1 file changed, 7 insert
From: David Daney
A couple of patches that make using SPI EEPROMs Real Easy for me.
David Daney (2):
misc/at25, dt: Improve at25 SPI eeprom device tree bindings.
misc/at25: Add an .id_table to at25 to facilitate driver loading and
binding.
Documentation/devicetree/bindings/misc/at25.tx
On Wed, Aug 22, 2012 at 08:39:06PM +0200, Linus Walleij wrote:
> On Wed, Aug 22, 2012 at 3:49 PM, Roland Stigge wrote:
>
> > Several SPI controller drivers have defined differently named properties for
> > the number of chip selects. Now adding "num-cs" as a reference name for new
> > bindings.
On Wed, Aug 22, 2012 at 3:49 PM, Roland Stigge wrote:
> Several SPI controller drivers have defined differently named properties for
> the number of chip selects. Now adding "num-cs" as a reference name for new
> bindings.
>
> Signed-off-by: Roland Stigge
Reviewed-by: Linus Walleij
Yours,
Li
On Wed, Aug 22, 2012 at 3:49 PM, Roland Stigge wrote:
> This patch adds device tree support to the spi-pl022 driver.
>
> Based on the initial patch by Alexandre Pereira da Silva
>
>
> Signed-off-by: Roland Stigge
> Acked-by: Alexandre Pereira da Silva
Reviewed-by: Linus Walleij
Yours,
Linu
On Wed, Aug 22, 2012 at 3:49 PM, Roland Stigge wrote:
> This patch adds the ability for the driver to control the chip select
> directly.
> This enables independence from cs_control callbacks. Configurable via
> platform_data, to be extended as DT in the following patch.
>
> Based on the initia
On Sat, Aug 18, 2012 at 09:06:27AM -0700, Guenter Roeck wrote:
> This driver adds support for NXP SC18IS602/603 I2C to SPI bus bridge.
>
> Signed-off-by: Guenter Roeck
Applied, thanks. One small thing:
> +static int sc18is602_probe(struct i2c_client *client,
> +const st
On 08/22/2012 10:19 AM, Stephen Warren wrote:
> Grant, Rob, Segher, Arnd, Olof,
>
> Can you please state if you agree with Mitch's opinion below? Thanks.
>
> On 08/16/2012 03:36 PM, Mitch Bradley wrote:
>> On 8/16/2012 9:34 AM, Stephen Warren wrote:
>>> As I understand it, there is a rule when wr
Signed-off-by: Chris Ball
---
Documentation/devicetree/bindings/mmc/mmc.txt | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt
b/Documentation/devicetree/bindings/mmc/mmc.txt
index 8a6811f..8e2e0ba 100644
--- a/Documentation
Hi Thomas,
On 8/22/2012 2:04 AM, Thomas Abraham wrote:
> On 22 August 2012 16:38, Chris Ball wrote:
>> Hi Thomas,
>>
>> On Wed, Aug 22 2012, Thomas Abraham wrote:
This matches Mitch's last suggestion exactly -- I think we're all agreed
on these properties now. The only remaining questi
On Wed, Aug 22, 2012 at 03:18:42PM +0800, Dong Aisheng wrote:
> From: Dong Aisheng
> Add regmap based imx syscon driver.
Nice to see more regmap-mmio usage!
Reviwed-by: Mark Brown
from a regmap point of view.
> +int imx_syscon_write(struct device_node *np, u32 reg, u32 val)
> +{
> + str
On Wed, Aug 22, 2012 at 03:18:45PM +0800, Dong Aisheng wrote:
> From: Dong Aisheng
>
> Using standard imx syscon API to access anatop register.
Acked-by: Mark Brown
With the conversion to regmap it'd also be good to convert the driver to
use the regmap helper functions for enable and voltage o
For a MX28 based hardware I am working with I need to use AUART4
I need to configure this AUART4 as uart only when necessary and at all
other times pins associated with AUART4 need to be configured as inputs.
I am using following DT definitions to setup AUART4 mux but can't
figure out how t
On 08/15/2012 08:38 AM, Linus Walleij wrote:
> (Hm maybe I should've read this patch first, well whatever.)
>
> On Fri, Aug 10, 2012 at 3:02 PM, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
>
>> This is also include the gpio controller as the IP share both.
>> Each soc will have to describe the SoC
Grant, Rob, Segher, Arnd, Olof,
Can you please state if you agree with Mitch's opinion below? Thanks.
On 08/16/2012 03:36 PM, Mitch Bradley wrote:
> On 8/16/2012 9:34 AM, Stephen Warren wrote:
>> As I understand it, there is a rule when writing device tree files (and
>> bindings) that nodes shoul
On 22 August 2012 20:24, Chris Ball wrote:
> Hi Thomas,
>
> On Wed, Aug 22 2012, Thomas Abraham wrote:
>>> none -> currently "samsung,sdhci-cd-internal"
>>> broken-cd -> currently "samsung,sdhci-cd-none"
>>> cd-gpios -> currently "samsung,sdhci-cd-gpios"
>>> non-removable -> curr
Hi Stephen,
On Wed, Aug 22 2012, Stephen Warren wrote:
> On 08/22/2012 04:17 AM, Chris Ball wrote:
>> Hi,
>>
>> On Wed, Aug 22 2012, Shawn Guo wrote:
>>> The following is what I have on my mind.
>>>
>>> broken-cd cd-gpiosimplication
>>> ---
>>> no
Hi Thomas,
On Wed, Aug 22 2012, Thomas Abraham wrote:
>> none -> currently "samsung,sdhci-cd-internal"
>> broken-cd -> currently "samsung,sdhci-cd-none"
>> cd-gpios -> currently "samsung,sdhci-cd-gpios"
>> non-removable -> currently "samsung,sdhci-cd-permanent"
>> cd-gpios + sams
On 08/22/2012 04:17 AM, Chris Ball wrote:
> Hi,
>
> On Wed, Aug 22 2012, Shawn Guo wrote:
>> The following is what I have on my mind.
>>
>> broken-cdcd-gpiosimplication
>> ---
>> no no SDHCI CD
>> no yes
Hi Shawn,
On Wed, Aug 22 2012, Shawn Guo wrote:
> mmc: sdhci: Always pass clock request value zero to set_clock host op
>
> To allow the set_clock host op to disable the SDCLK source when not
> needed, always call the host op when the requested clock speed is
> zero. Do this even
This patch adds device tree support to the spi-pl022 driver.
Based on the initial patch by Alexandre Pereira da Silva
Signed-off-by: Roland Stigge
Acked-by: Alexandre Pereira da Silva
---
Documentation/devicetree/bindings/spi/spi_pl022.txt | 15 +++
drivers/spi/spi-pl022.c
This patch adds the ability for the driver to control the chip select directly.
This enables independence from cs_control callbacks. Configurable via
platform_data, to be extended as DT in the following patch.
Based on the initial patch by Alexandre Pereira da Silva
Signed-off-by: Roland Stigge
Several SPI controller drivers have defined differently named properties for
the number of chip selects. Now adding "num-cs" as a reference name for new
bindings.
Signed-off-by: Roland Stigge
---
Documentation/devicetree/bindings/spi/spi-bus.txt |3 +++
1 file changed, 3 insertions(+)
---
>> Converted the existing arch-vt8500 gpio to a platform_device.
>> Added support for WM8505 and WM8650 GPIO controllers.
>(...)
>> + unsigned val;
>I asked about the datatype for this "val", it sure isn't "unsigned".
>I suspected the registers were only 8bit and so it should be u8.
>But at
It really becomes a maintenance issue that every time a device needs
to look up (clk_get) a clock we have to patch kernel clock file to call
clk_register_clkdev for that clock.
Since clock DT support which is meant to resolve clock lookup in device
tree is in place, the patch moves imx23 client de
It really becomes a maintenance issue that every time a device needs
to look up (clk_get) a clock we have to patch kernel clock file to call
clk_register_clkdev for that clock.
Since clock DT support which is meant to resolve clock lookup in device
tree is in place, the patch moves imx28 client de
It really becomes an maintenance issue that every time a device needs
to look up (clk_get) a clock we have to patch kernel clock file to call
clk_register_clkdev for that clock.
Since clock DT support which is meant to resolve clock lookup in device
tree is in place, the patch moves imx6q client d
For those SoCs that have hundreds of clock outputs, their clock
DT bindings could reasonably define #clock-cells as 1 and require
the client device specify the index of the clock it consumes in the
cell of its "clocks" phandle.
Add a generic of_clk_src_onecell_get() function for this purpose.
Sig
Change since v1:
* Rewrite of_clk_src_onecell_get() to get the clk using the index
provided by device tree and the clks array provided by clock driver.
Then we can save that big clock name list in dts and the string
matching which is relatively slow.
Shawn Guo (4):
clk: add of_clk_src_one
On Wed, Aug 22, 2012 at 6:04 PM, Arnd Bergmann wrote:
> On Wednesday 22 August 2012, Kishon Vijay Abraham I wrote:
>> This patch series has been lying here for long. If no one has any
>> comments on this patch series, can someone pick it up?
>
> I've added them now as a drivers/ocp2scp branch arm-
On Wednesday 22 August 2012, Kishon Vijay Abraham I wrote:
> This patch series has been lying here for long. If no one has any
> comments on this patch series, can someone pick it up?
I've added them now as a drivers/ocp2scp branch arm-soc and pulled
them into the next/drivers topic branch.
Hi Chris,
On Tue, Aug 21, 2012 at 10:48:43AM -0400, Chris Ball wrote:
> Aside: the bindings do not match the code. The bindings document says
> to use "fsl,cd-internal", and imx51-babbage.dts does so -- but the code
> doesn't check for "fsl,cd-internal", it checks for "fsl,cd-controller":
>
>
nvpublic
> On Sun, Aug 19, 2012 at 06:07:55PM -0700, Bill Huang wrote:
> > Add DT property "ti,system-power-controller" telling whether or not
> > this pmic is in charge of controlling the system power, so the power
> > off routine can be hooked up to system call "pm_power_off".
> >
> > Based on th
On 22 August 2012 16:38, Chris Ball wrote:
> Hi Thomas,
>
> On Wed, Aug 22 2012, Thomas Abraham wrote:
>>> This matches Mitch's last suggestion exactly -- I think we're all agreed
>>> on these properties now. The only remaining question is how to handle
>>> the pinctrl for CD in Thomas's case.
>>
On Wed, Aug 22, 2012 at 04:52:36PM +0800, Zhao Richard-B20223 wrote:
> On Wed, Aug 22, 2012 at 03:18:47PM +0800, Dong Aisheng wrote:
> > From: Dong Aisheng
> >
> > Originally the anatop regulator devices are populated by mfd anatop driver.
> > Since mfd anatop driver will be deleted later, we cha
On Wed, Aug 22, 2012 at 04:29:41PM +0800, Zhao Richard-B20223 wrote:
> On Wed, Aug 22, 2012 at 03:18:42PM +0800, Dong Aisheng wrote:
> > From: Dong Aisheng
> >
> > Add regmap based imx syscon driver.
> > This is usually used for access misc bits in registers which does not belong
> > to a specifi
On Tue, Aug 21, 2012 at 6:01 PM, Roland Stigge wrote:
> This patch adds device tree support to the spi-pl022 driver.
(...)
> --- linux-2.6.orig/Documentation/devicetree/bindings/spi/spi_pl022.txt
> +++ linux-2.6/Documentation/devicetree/bindings/spi/spi_pl022.txt
> @@ -6,7 +6,22 @@ Required prop
On Tue, Aug 21, 2012 at 6:00 PM, Roland Stigge wrote:
> This patch adds the ability for the driver to control the chip select
> directly.
> This enables independence from cs_control callbacks. Configurable via
> platform_data, to be extended as DT in the following patch.
>
> Based on the initia
Hi Thomas,
On Wed, Aug 22 2012, Thomas Abraham wrote:
>> This matches Mitch's last suggestion exactly -- I think we're all agreed
>> on these properties now. The only remaining question is how to handle
>> the pinctrl for CD in Thomas's case.
>
> Hi Chris,
>
> For sdhci-s3c driver, the 'broken-cd
On 22 August 2012 15:47, Chris Ball wrote:
> Hi,
>
> On Wed, Aug 22 2012, Shawn Guo wrote:
>> The following is what I have on my mind.
>>
>> broken-cd cd-gpiosimplication
>> ---
>> nono SDHCI CD
>> noyes
Hi,
On Wed, Aug 22 2012, Shawn Guo wrote:
> The following is what I have on my mind.
>
> broken-cd cd-gpiosimplication
> ---
> nono SDHCI CD
> noyes GPIO CD
> yes no NO CD /
On Wed, Aug 22, 2012 at 09:32:23AM +0100, Russell King - ARM Linux wrote:
> On Tue, Aug 21, 2012 at 08:11:57AM -0500, Rob Herring wrote:
> > On 08/21/2012 07:27 AM, Russell King - ARM Linux wrote:
> > > So now, you're not dealing with inventing a whole load of names for clocks
> > > on a platform,
On Tue, Aug 21, 2012 at 10:47 PM, Tony Prisk wrote:
> Converted the existing arch-vt8500 gpio to a platform_device.
> Added support for WM8505 and WM8650 GPIO controllers.
(...)
> + unsigned val;
I asked about the datatype for this "val", it sure isn't "unsigned".
I suspected the register
On Wed, Aug 22, 2012 at 03:18:47PM +0800, Dong Aisheng wrote:
> From: Dong Aisheng
>
> Originally the anatop regulator devices are populated by mfd anatop driver.
> Since mfd anatop driver will be deleted later, we change to populate the
> regulator devices by devicetree automatically.
> This wil
Add ocp2scp data node in omap4 device tree file.
Acked-by: Felipe Balbi
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap4.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 04cbbcb..8a780b2 100644
Adds a new driver *omap-ocp2scp*. This driver takes the responsibility of
creating all the devices that is connected to OCP2SCP. In the case of OMAP4,
USB2PHY is connected to ocp2scp.
This also includes device tree support for ocp2scp driver and
the documentation with device tree binding informati
This patch series has been lying here for long. If no one has any
comments on this patch series, can someone pick it up?
This patch series is done as a preparatory step for adding phy drivers
for dwc3 and musb.
This series adds a new driver for ocp2scp (only dt) to which phy
drivers are connected
On Tue, Aug 21, 2012 at 08:11:57AM -0500, Rob Herring wrote:
> On 08/21/2012 07:27 AM, Russell King - ARM Linux wrote:
> > So now, you're not dealing with inventing a whole load of names for clocks
> > on a platform, instead what you're doing is describing _where_ the clock
> > comes from in the sy
On Wed, Aug 22, 2012 at 03:18:42PM +0800, Dong Aisheng wrote:
> From: Dong Aisheng
>
> Add regmap based imx syscon driver.
> This is usually used for access misc bits in registers which does not belong
> to a specific module, for example, IOMUXC GPR and ANATOP.
> With this driver, we provide a st
From: Dong Aisheng
The anatop registers are accessed via imx syscon now, no one will use
mfd anatop driver anymore, remove it.
Signed-off-by: Dong Aisheng
---
drivers/mfd/Kconfig|8 ---
drivers/mfd/Makefile |1 -
drivers/mfd/anatop-mfd.c | 124 -
From: Dong Aisheng
Using standard imx syscon API to access anatop registers.
Signed-off-by: Dong Aisheng
---
arch/arm/mach-imx/Kconfig |2 +-
arch/arm/mach-imx/mach-imx6q.c | 25 ++---
2 files changed, 7 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-
From: Dong Aisheng
Originally the anatop regulator devices are populated by mfd anatop driver.
Since mfd anatop driver will be deleted later, we change to populate the
regulator devices by devicetree automatically.
This will cause some warning messages as follows during boot due to device
recreat
From: Dong Aisheng
Using standard imx syscon API to access anatop register.
Signed-off-by: Dong Aisheng
---
arch/arm/boot/dts/imx6q.dtsi |6 ++
drivers/regulator/Kconfig|2 +-
drivers/regulator/anatop-regulator.c | 17 +++--
3 files changed, 18 ins
From: Dong Aisheng
There're a few anatop registers need to be accessed by different modules.
Add anatop registers into imx-syscon support for easy access.
Signed-off-by: Dong Aisheng
---
arch/arm/boot/dts/imx6q.dtsi |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/ar
From: Dong Aisheng
Include headfile for easy using.
Signed-off-by: Dong Aisheng
---
arch/arm/boot/dts/imx6q.dtsi |5 +
include/linux/fsl/imx6q-iomuxc-gpr.h | 319 ++
2 files changed, 324 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/
From: Dong Aisheng
Add regmap based imx syscon driver.
This is usually used for access misc bits in registers which does not belong
to a specific module, for example, IOMUXC GPR and ANATOP.
With this driver, we provide a standard API for client driver to call to
access registers which are registe
This patch series mainly adds an imx-syscon driver which is used to access
general system controller registers like IOMUXC GPR and ANATOP,
after that, we convert all the exist private access general registers code to
use
standard API from imx-syscon to access registers.
Finally we remove the old m
92 matches
Mail list logo
