Hi,
On Thu, Mar 14, 2013 at 4:23 PM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Mar 14, 2013 at 04:14:58PM +0530, Vivek Gautam wrote:
>> Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare
>> calls as required by common clock framework.
>>
>> Signed-off-by: Vivek Gautam
>> CC:
On Thu, Mar 14, 2013 at 01:35:47PM +0100, Hector Palacios wrote:
> On 03/14/2013 11:02 AM, Hector Palacios wrote:
> >Hello,
> >
> >Maybe I'm missing something but the MXS processors (at least i.MX23 and
> >i.MX28) cannot
> >set the polarity of the GPIOs, so shouldn't the #gpio-cells be 1?
> >
> >(
On Friday 15 March 2013 02:28 AM, Nishanth Menon wrote:
> The following series arose from trying to use BeagleBoard-XM (OMAP3 variant)
> for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in
> migrating the cpufreq support only through device tree (part of the effort
> to mig
On Fri, Mar 15, 2013 at 2:28 AM, Nishanth Menon wrote:
> We can now use cpufreq-cpu0 driver using DT entries.
> remove the redundant omap-cpufreq driver from the tree.
> Remove MAINTAINERS file entry for the same as well.
>
> Cc: Kevin Hilman
> Cc: "Benoît Cousson"
> Cc: Santosh Shilimkar
> Cc:
On 3/14/2013 9:14 PM, Peter Korsgaard wrote:
>> "Sekhar" == Sekhar Nori writes:
>
> >> Required properties:
> >> -- compatible: Must be "ti,am33xx-ecap"
> >> +- compatible: Must be "ti,am33xx-ecap" or "ti,da850-ecap"
> >> - #pwm-cells: Should be 3. Number of cells being used to specify PW
Hi,
On 13 March 2013 20:09, Rob Herring wrote:
> The subject is completely misleading. Make it clear what the scope of
> this patch is.
>
> On 03/13/2013 06:26 AM, Vikas Sajjan wrote:
>> The FIMD driver expects the "vsync" interrupt to be mentioned as the 1st
>> parameter in the FIMD DT node. So
On Thu, Mar 14, 2013 at 02:08:32PM +0100, Markus Pargmann wrote:
> On Wed, Mar 13, 2013 at 10:18:29AM +0800, Shawn Guo wrote:
> > On Tue, Mar 12, 2013 at 07:02:07PM +, Mark Brown wrote:
> > > On Sun, Mar 10, 2013 at 07:33:09PM +0100, Markus Pargmann wrote:
> > > > Add a function to open a DMA P
On Friday, March 15, 2013 8:01 AM, Doug Anderson wrote:
>
> The exynox4210-ehci and exynos4210-ohci nodes need a clock specified
> using the common clock framework. Document it.
>
> Signed-off-by: Doug Anderson
It looks good.
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> Changes in
The exynox4210-ehci and exynos4210-ohci nodes need a clock specified
using the common clock framework. Document it.
Signed-off-by: Doug Anderson
---
Changes in v2:
- Fixed embarrassing typo adc=>usb. Thanks Jingoo!
Documentation/devicetree/bindings/usb/exynos-usb.txt | 10 ++
1 file c
On Friday, March 15, 2013 8:01 AM, Doug Anderson wrote:
>
> The exynox4210-ehci and exynos4210-ohci nodes need a clock specified
> using the common clock framework. Document it.
>
> Signed-off-by: Doug Anderson
> ---
> Documentation/devicetree/bindings/usb/exynos-usb.txt | 10 ++
> 1 f
On Thu, Mar 14, 2013 at 02:04:45PM +0800, Shawn Guo wrote:
> I just double checked my mailbox and can only see the conversation
> between you and rmk, nothing particularly on the removal of the const
> from the name parameter. Or I'm still missing something?
You're missing the bit where I compla
The exynox4210-ehci and exynos4210-ohci nodes need a clock specified
using the common clock framework. Document it.
Signed-off-by: Doug Anderson
---
Documentation/devicetree/bindings/usb/exynos-usb.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bind
On Thursday 14 March 2013, Anatolij Gustschin wrote:
> I wanted to avoid additional levels of indirection and function calls
> on i.MX. If something like
>
> static inline u32 mxcmci_readl(struct mxcmci_host *host, int reg)
> {
> #if IS_ENABLED(CONFIG_PPC_MPC512x)
> return in_be32(host->ba
On Thu, Mar 14, 2013 at 10:29 PM, Jon Hunter wrote:
>
> On 03/14/2013 04:08 PM, Javier Martinez Canillas wrote:
>>
>>
>> Javier
>>
>> Hi Jon,
>>
>> On 14/03/2013, at 21:43, Jon Hunter wrote:
>>
>>>
>>> On 03/14/2013 03:33 PM, Javier Martinez Canillas wrote:
Besides being used to interface wi
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
This patch allows an ethernet chip to be defined as an GPMC
child device
On 03/14/2013 03:58 PM, Nishanth Menon wrote:
> OMAP4430 and 4460 have different OPP definitions. So, create an SoC
> variant dtsi file for 4460 and move the OPP definitions to it.
FYI, I had to create a similar file for PMU [1]. However, I called it
omap4460.dtsi and not omap446x.dtsi as there i
On 03/14/2013 03:58 PM, Nishanth Menon wrote:
> Add DT OPP table for OMAP36xx family of devices. This data is
> decoded by OF with of_init_opp_table() helper function. This
> overrides the default OMAP34xx CPU OPP table definition.
Not sure I following the last sentence. The tables are in a diffe
On 03/14/2013 03:58 PM, Nishanth Menon wrote:
> Add DT OPP table for OMAP34xx family of devices. This data is
> decoded by OF with of_init_opp_table() helper function.
>
> This is in preparation to use generic cpu0-cpufreq driver.
No mention here about what you are removing ;-)
Jon
On 03/14/2013 03:58 PM, Nishanth Menon wrote:
> The following series arose from trying to use BeagleBoard-XM (OMAP3 variant)
> for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in
> migrating the cpufreq support only through device tree (part of the effort
> to migrate away
On Thu, Mar 14, 2013 at 03:29:21PM -0600, Jason Gunthorpe wrote:
> On Thu, Mar 14, 2013 at 10:09:26PM +0100, Thierry Reding wrote:
>
> > > ranges = <0x8200 0 0x8000 0x8000 0 0x1000 /* port 0
> > > registers */
> > > 0x8200 0 0x80001000 0x80001000 0 0x1000 /* po
On Thu, Mar 14, 2013 at 10:09:26PM +0100, Thierry Reding wrote:
> > ranges = <0x8200 0 0x8000 0x8000 0 0x1000 /* port 0
> > registers */
> > 0x8200 0 0x80001000 0x80001000 0 0x1000 /* port 1
> > registers */
> > 0x8100 0 0 0x8200 0 0
On 03/14/2013 04:08 PM, Javier Martinez Canillas wrote:
>
>
> Javier
>
> Hi Jon,
>
> On 14/03/2013, at 21:43, Jon Hunter wrote:
>
>>
>> On 03/14/2013 03:33 PM, Javier Martinez Canillas wrote:
>>> Besides being used to interface with external memory devices,
>>> the General-Purpose Memory Con
On Thu, 14 Mar 2013 21:11:39 +0100
Sascha Hauer wrote:
> On Thu, Mar 14, 2013 at 05:40:53PM +0100, Anatolij Gustschin wrote:
> > Add SDHC DMA channel description to the mpc512x device
> > tree to enable slave channel requesting in the mxcmmc
> > driver.
> >
> > mpc512x DMA engine doesn't support
On Thu, Mar 14, 2013 at 11:25:55AM -0600, Jason Gunthorpe wrote:
[...]
> I'm assuming 0x8000, 0xa000 and 0xb000 are real CPU physical
> addresses?
>
> Then it should probably look like:
>
> ranges = <0x8200 0 0x8000 0x8000 0 0x1000 /* port 0
> registers */
>
Javier
Hi Jon,
On 14/03/2013, at 21:43, Jon Hunter wrote:
>
> On 03/14/2013 03:33 PM, Javier Martinez Canillas wrote:
>> Besides being used to interface with external memory devices,
>> the General-Purpose Memory Controller can be used to connect
>> Pseudo-SRAM devices such as ethernet contr
On Thu, Mar 14, 2013 at 09:38:58PM +0100, Thierry Reding wrote:
> >pci@1,0 {
> > device_type = "pci";
> > assigned-addresses = <0x8200 0 0x8000 0
> > 0x1000>;
Sorry, I missed this. The b,d,f bits should be set:
PandaBoard, PandaBoard-A4 revisions use OMAP4430.
PandaBoard-ES version of the board uses OMAP4460.
Move the original panda dts file into a common dtsi used by all panda
variants. This allows us to introduce SoC variation for PandaBoard ES
without impacting other PandaBoard versions that are suppo
We can now use cpufreq-cpu0 driver using DT entries.
remove the redundant omap-cpufreq driver from the tree.
Remove MAINTAINERS file entry for the same as well.
Cc: Kevin Hilman
Cc: "Benoît Cousson"
Cc: Santosh Shilimkar
Cc: Shawn Guo
Cc: Keerthy
Cc: linux-o...@vger.kernel.org
Cc: devicetree-
Define VDD1 regulator in twl4030 DT and mark it as the supply for the
various OMAP3 platforms.
Cc: Kevin Hilman
Cc: "Benoît Cousson"
Cc: Santosh Shilimkar
Cc: Shawn Guo
Cc: Keerthy
Cc: linux-o...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
With OMAP3+ and AM33xx supported SoC having defined CPU DT
entries with operating-points defined, we can now
use the SoC generic cpu0-cpufreq driver to start
using it, lets now switch to the generic driver.
As part of this change, switch the dummy clock node to use
cpufreq-cpu0. This is an suggest
OMAP4430 and 4460 have different OPP definitions. So, create an SoC
variant dtsi file for 4460 and move the OPP definitions to it.
Add DT OPP table for OMAP446x family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
This is in preparation to use generic cpu0-cpufre
Add DT OPP table for OMAP36xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function. This
overrides the default OMAP34xx CPU OPP table definition.
This is in preparation to use generic cpu0-cpufreq driver.
Cc: Kevin Hilman
Cc: "Benoît Cousson"
Cc: Santosh Shilim
Add DT OPP table for OMAP443x family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
This is in preparation to use generic cpu0-cpufreq driver.
Cc: Kevin Hilman
Cc: "Benoît Cousson"
Cc: Santosh Shilimkar
Cc: Shawn Guo
Cc: Keerthy
Cc: linux-o...@vger.kernel.or
The following series arose from trying to use BeagleBoard-XM (OMAP3 variant)
for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in
migrating the cpufreq support only through device tree (part of the effort
to migrate away from non-DT configurations for OMAP). Unfortunately, a
Add DT OPP table for OMAP34xx family of devices. This data is
decoded by OF with of_init_opp_table() helper function.
This is in preparation to use generic cpu0-cpufreq driver.
Cc: Kevin Hilman
Cc: "Benoît Cousson"
Cc: Santosh Shilimkar
Cc: Shawn Guo
Cc: Keerthy
Cc: linux-o...@vger.kernel.or
On 03/14/2013 03:33 PM, Javier Martinez Canillas wrote:
> Besides being used to interface with external memory devices,
> the General-Purpose Memory Controller can be used to connect
> Pseudo-SRAM devices such as ethernet controllers to OMAP2+
> processors using the TI GPMC as a data bus.
>
> Thi
On Thu, Mar 14, 2013 at 11:25:55AM -0600, Jason Gunthorpe wrote:
> [trimm'd the cc list]
>
> On Thu, Mar 14, 2013 at 10:01:20AM +0100, Thierry Reding wrote:
>
> > It turns out that this works with the Tegra driver because it uses the
> > new of_pci_process_ranges() function and simply overwrites
On Thu, Mar 14, 2013 at 08:32:57PM +0100, Florian Fainelli wrote:
> Hello Jason,
>
> Le 14/03/2013 20:02, Jason Cooper a écrit :
> >Florian,
> >
> >On Thu, Mar 14, 2013 at 07:08:32PM +0100, Florian Fainelli wrote:
> >>This patch converts the Marvell MV643XX ethernet driver to use the
> >>Marvell O
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
This patch allows an ethernet chip to be defined as an GPMC
child device
On Thu, Mar 14, 2013 at 7:49 PM, Jon Hunter wrote:
>
> On 03/14/2013 11:37 AM, Javier Martinez Canillas wrote:
>> On Thu, Mar 14, 2013 at 4:48 PM, Jon Hunter wrote:
>>> Hi Javier,
>>>
>>> On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
Besides being used to interface with external me
On Thu, Mar 14, 2013 at 05:40:53PM +0100, Anatolij Gustschin wrote:
> Add SDHC DMA channel description to the mpc512x device
> tree to enable slave channel requesting in the mxcmmc
> driver.
>
> mpc512x DMA engine doesn't support endianness conversion
> when reading/writing data from peripheral's
On Thu, Mar 14, 2013 at 07:13:32PM +0100, Anatolij Gustschin wrote:
> On Thu, 14 Mar 2013 17:50:08 +0100
> Arnd Bergmann wrote:
>
> > On Thursday 14 March 2013 17:40:49 Anatolij Gustschin wrote:
> >
> > > +
> > > +struct mxcmci_reg_ops mxcmci_reg_ops = {
> > > + .read_l = mpcmci_readl,
> > > + .
Hello Jason,
Le 14/03/2013 20:02, Jason Cooper a écrit :
Florian,
On Thu, Mar 14, 2013 at 07:08:32PM +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 MV643
Florian,
On Thu, Mar 14, 2013 at 07:08:32PM +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 Mar
On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
> The gpmc_probe_nor_child() function is used in the GPMC driver to
> configure the GPMC for a NOR child device node.
>
> But this function is quite generic and all the NOR specific configuration
> is made by the driver of the actual NOR fla
On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
> gpmc_probe_nor_child() calls of_platform_device_create() to create a
> platform device for the NOR child. If this function fails the value
> of ret is returned to the caller but this value is zero since it was
> assigned the return of a pr
On 03/14/2013 11:37 AM, Javier Martinez Canillas wrote:
> On Thu, Mar 14, 2013 at 4:48 PM, Jon Hunter wrote:
>> Hi Javier,
>>
>> On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
>>> Besides being used to interface with external memory devices,
>>> the General-Purpose Memory Controller can
This patch changes the mvmdio driver not to use device tree
helper functions such as of_mdiobus_register() and of_iomap() so we can
instantiate this driver using a classic platform_device approach. Use
the device manager helper to ioremap() the base register cookie so we
get automatic freeing upon
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 s
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 s
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: Flor
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.
Acked-by: Thomas Petazzoni
Signed-off-by: Florian Fai
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 lin
On Thu, Mar 14, 2013 at 07:09:18PM +0100, Florian Fainelli wrote:
> Hello Jason,
>
> Le 03/14/13 18:25, Jason Cooper a écrit :
> >Florian,
> >
> >Any word on version 2 of this series? I'd like to base the conversion
> >of kirkwood to DT based ethernet init on it.
>
> Just sent them out for revie
On Thu, 14 Mar 2013 17:40:52 +0100
Anatolij Gustschin wrote:
> Fix:
> drivers/mmc/host/mxcmmc.c: In function 'mxcmci_probe':
> drivers/mmc/host/mxcmmc.c:1137:41: warning: initialization discards
> 'const' qualifier from pointer target type [enabled by default]
>
> Signed-off-by: Anatolij Gustsch
On Thu, 14 Mar 2013 17:50:08 +0100
Arnd Bergmann wrote:
> On Thursday 14 March 2013 17:40:49 Anatolij Gustschin wrote:
>
> > +
> > +struct mxcmci_reg_ops mxcmci_reg_ops = {
> > + .read_l = mpcmci_readl,
> > + .write_l = mpcmci_writel,
> > + .read_w = mpcmci_readw,
> > + .write_w = mpcmci
Hello Jason,
Le 03/14/13 18:25, Jason Cooper a écrit :
Florian,
Any word on version 2 of this series? I'd like to base the conversion
of kirkwood to DT based ethernet init on it.
Just sent them out for review, thanks for reminder, they were sitting in
my tree for a couple days already.
--
On 03/14/2013 04:02 AM, Hector Palacios wrote:
> Hello,
>
> Maybe I'm missing something but the MXS processors (at least i.MX23 and
> i.MX28) cannot set the polarity of the GPIOs, so shouldn't the
> #gpio-cells be 1?
>
> (From Documentation/devicetree/bindings/gpio/fsl-imx-gpio.txt):
>
> - #gpio
Florian,
Any word on version 2 of this series? I'd like to base the conversion
of kirkwood to DT based ethernet init on it.
thx,
Jason.
On Tue, Jan 29, 2013 at 04:24:03PM +0100, Florian Fainelli wrote:
> Hi all,
>
> This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
[trimm'd the cc list]
On Thu, Mar 14, 2013 at 10:01:20AM +0100, Thierry Reding wrote:
> It turns out that this works with the Tegra driver because it uses the
> new of_pci_process_ranges() function and simply overwrites earlier
> matches by subsequent ones.
>
> ranges = <0x8200 0 0 0x8
On Thu, Mar 14, 2013 at 5:37 PM, Javier Martinez Canillas
wrote:
> On Thu, Mar 14, 2013 at 4:48 PM, Jon Hunter wrote:
>> Hi Javier,
>>
>> On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
>>> Besides being used to interface with external memory devices,
>>> the General-Purpose Memory Contro
* Roger Quadros [130314 08:45]:
>
> OK. Let me know how the below patch looks. After that, the board code
> will look like.
>
> static struct usbhs_phy_data phy_data[] = {
> {
> .reset_gpio = 147,
> .vcc_gpio = 148
> .vcc_polarity = 1,
>
On Thursday 14 March 2013 17:40:49 Anatolij Gustschin wrote:
> +
> +struct mxcmci_reg_ops mxcmci_reg_ops = {
> + .read_l = mpcmci_readl,
> + .write_l = mpcmci_writel,
> + .read_w = mpcmci_readw,
> + .write_w = mpcmci_writew,
> +};
> +#else
> +struct mxcmci_reg_ops mxcmci_reg_ops;
>
mxcmci_dma_callback() is invoked by DMA drivers in soft-irq
context and can be interrupted by the mxcmci_irq() interrupt
which can finish the mmc request or data transfer and set
host->req or host->data pointers to NULL. Then mxcmci_data_done()
crashes with a null pointer dereferences. Protect all
Add SDHC DMA channel description to the mpc512x device
tree to enable slave channel requesting in the mxcmmc
driver.
mpc512x DMA engine doesn't support endianness conversion
when reading/writing data from peripheral's FIFO, so we
have to swap data buffers before each DMA write and after
each DMA r
Fix:
drivers/mmc/host/mxcmmc.c: In function 'mxcmci_probe':
drivers/mmc/host/mxcmmc.c:1137:41: warning: initialization discards
'const' qualifier from pointer target type [enabled by default]
Signed-off-by: Anatolij Gustschin
---
drivers/mmc/host/mxcmmc.c |4 ++--
1 files changed, 2 insertio
The SDHC controller on mpc512x is compatible with i.MX31 SDHC
controller, the existing MMC host driver can be used on
mpc512x with some modifications, the patch series extends
the existing driver. It is based on the following mxcmmc DT
support patch:
http://thread.gmane.org/gmane.linux.kernel.mmc
Fix:
drivers/mmc/host/mxcmmc.c: In function 'mxcmci_probe':
drivers/mmc/host/mxcmmc.c:1137:41: warning: initialization discards
'const' qualifier from pointer target type [enabled by default]
Signed-off-by: Anatolij Gustschin
---
drivers/mmc/host/mxcmmc.c |4 ++--
1 files changed, 2 insertio
slot-gpio API suppors read-only detection when "wp-gpios"
property is present in the device tree mmc node. Use this
API for write-protect detection.
Signed-off-by: Anatolij Gustschin
---
drivers/mmc/host/mxcmmc.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/dri
The SDHC controller on mpc512x is compatible with i.MX31 SDHC,
so the mxcmmc driver can be used on mpc512x, too. Extend the
driver to support mpc512x as well.
Signed-off-by: Anatolij Gustschin
---
drivers/mmc/host/Kconfig | 10 +-
drivers/mmc/host/mxcmmc.c | 222 +
On Thu, Mar 14, 2013 at 4:48 PM, Jon Hunter wrote:
> Hi Javier,
>
> On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
>> Besides being used to interface with external memory devices,
>> the General-Purpose Memory Controller can be used to connect
>> Pseudo-SRAM devices such as ethernet contr
On Thu, Mar 14, 2013 at 04:50:48PM +0100, Anatolij Gustschin wrote:
> On Mon, 25 Feb 2013 19:28:05 +0100
> Markus Pargmann wrote:
>
> > Adding devicetree support for imx21-mmc and imx31-mmc. Based on generic
> > gpio helper functions by Guennadi and generic DMA devicetree bindings.
> >
> > Signe
Hi Javier,
On 03/14/2013 05:02 PM, Javier Martinez Canillas wrote:
> On Thu, Mar 14, 2013 at 3:57 PM, Benoit Cousson wrote:
>> Salut Jon,
>>
>> On 03/08/2013 06:27 PM, Jon Hunter wrote:
>>> Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
>>>
>>> The DMA, PMU and OMAP3430 SDP
On 03/14/2013 04:59 PM, Jon Hunter wrote:
>
> On 03/14/2013 10:45 AM, Florian Vaussard wrote:
>> Hi Benoit,
>>
>> On 03/14/2013 03:57 PM, Benoit Cousson wrote:
>>> Salut Jon,
>>>
>>> On 03/08/2013 06:27 PM, Jon Hunter wrote:
Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards
On 03/14/2013 11:02 AM, Javier Martinez Canillas wrote:
> On Thu, Mar 14, 2013 at 3:57 PM, Benoit Cousson wrote:
>> Salut Jon,
>>
>> On 03/08/2013 06:27 PM, Jon Hunter wrote:
>>> Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
>>>
>>> The DMA, PMU and OMAP3430 SDP board chan
On 03/14/2013 05:00 PM, Jon Hunter wrote:
>
>
> On 03/14/2013 10:58 AM, Benoit Cousson wrote:
>> On 03/14/2013 04:50 PM, Jon Hunter wrote:
>>>
>>> On 03/14/2013 10:45 AM, Benoit Cousson wrote:
On 03/11/2013 06:56 PM, Jon Hunter wrote:
>
> On 03/09/2013 06:42 AM, Ezequiel Garcia wrote
On Thursday 14 March 2013, Thomas Gleixner wrote:
> > But if its arch specific for hardware I don't have, I'd really prefer the
> > arch
> > maintainer be the upstream path.
> >
> > Thomas: Am I being too obstinate here? If not, should we drop "F:
> > drivers/clocksource" from the MAINTAINERS en
On Thu, Mar 14, 2013 at 3:57 PM, Benoit Cousson wrote:
> Salut Jon,
>
> On 03/08/2013 06:27 PM, Jon Hunter wrote:
>> Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
>>
>> The DMA, PMU and OMAP3430 SDP board changes have been sent before
>> individually but re-sending here as
Hi Florian,
On 01/28/2013 06:54 PM, Florian Vaussard wrote:
> Add device-tree support for the GPMC controller on the OMAP3.
>
> Signed-off-by: Florian Vaussard
Applied and pushed.
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.10/dts
Regards,
Benoit
__
On 03/14/2013 10:58 AM, Benoit Cousson wrote:
> On 03/14/2013 04:50 PM, Jon Hunter wrote:
>>
>> On 03/14/2013 10:45 AM, Benoit Cousson wrote:
>>> On 03/11/2013 06:56 PM, Jon Hunter wrote:
On 03/09/2013 06:42 AM, Ezequiel Garcia wrote:
> On Fri, Mar 8, 2013 at 10:25 PM, Javier Martin
On 03/14/2013 10:45 AM, Florian Vaussard wrote:
> Hi Benoit,
>
> On 03/14/2013 03:57 PM, Benoit Cousson wrote:
>> Salut Jon,
>>
>> On 03/08/2013 06:27 PM, Jon Hunter wrote:
>>> Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
>>>
>>> The DMA, PMU and OMAP3430 SDP board change
On 03/14/2013 04:50 PM, Jon Hunter wrote:
>
> On 03/14/2013 10:45 AM, Benoit Cousson wrote:
>> On 03/11/2013 06:56 PM, Jon Hunter wrote:
>>>
>>> On 03/09/2013 06:42 AM, Ezequiel Garcia wrote:
On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas
wrote:
> On Fri, Mar 8, 2013 at 1
On Thu, Mar 14, 2013 at 12:50 PM, Jon Hunter wrote:
>> Yes, I full agree with that as well. The size should be purely HW
>> related. So we should not take any assumption about the page size /
>> alignment.
>
> Ok, what is best to use? The size from hwmod structures or the size from
> the documenta
Hi Benoit,
On 03/14/2013 03:57 PM, Benoit Cousson wrote:
Salut Jon,
On 03/08/2013 06:27 PM, Jon Hunter wrote:
Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
The DMA, PMU and OMAP3430 SDP board changes have been sent before
individually but re-sending here as a complete
On 03/14/2013 10:45 AM, Benoit Cousson wrote:
> On 03/11/2013 06:56 PM, Jon Hunter wrote:
>>
>> On 03/09/2013 06:42 AM, Ezequiel Garcia wrote:
>>> On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas
>>> wrote:
On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter wrote:
>
> Yes you are
On Mon, 25 Feb 2013 19:28:05 +0100
Markus Pargmann wrote:
> Adding devicetree support for imx21-mmc and imx31-mmc. Based on generic
> gpio helper functions by Guennadi and generic DMA devicetree bindings.
>
> Signed-off-by: Markus Pargmann
> ---
> .../devicetree/bindings/mmc/fsl-imx-mmc.txt
Hi Javier,
On 03/14/2013 10:09 AM, Javier Martinez Canillas wrote:
> Besides being used to interface with external memory devices,
> the General-Purpose Memory Controller can be used to connect
> Pseudo-SRAM devices such as ethernet controllers to OMAP2+
> processors using the TI GPMC as a data bu
On 03/11/2013 06:56 PM, Jon Hunter wrote:
>
> On 03/09/2013 06:42 AM, Ezequiel Garcia wrote:
>> On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas
>> wrote:
>>> On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter wrote:
Yes you are correct. In general, I have been trying to stay some-wh
> "Sekhar" == Sekhar Nori writes:
>> Required properties:
>> -- compatible: Must be "ti,am33xx-ecap"
>> +- compatible: Must be "ti,am33xx-ecap" or "ti,da850-ecap"
>> - #pwm-cells: Should be 3. Number of cells being used to specify PWM
>> property.
>> First cell specifies the per-chip i
On 03/13/2013 06:57 PM, Tony Lindgren wrote:
> * Roger Quadros [130313 09:40]:
>> On 03/13/2013 06:24 PM, Tony Lindgren wrote:
>>> * Roger Quadros [130313 06:46]:
On 03/12/2013 06:40 PM, Tony Lindgren wrote:
> * Roger Quadros [130312 04:47]:
>> Hi Tony,
>>
>> These patches p
On Thu, Mar 14, 2013 at 12:54:08PM +, Philip, Avinash wrote:
> On Thu, Mar 14, 2013 at 17:09:04, Nori, Sekhar wrote:
> > On 3/14/2013 4:02 PM, Philip Avinash wrote:
> > > Add EHRPWM and ECAP support build support for DAVINCI_DA850 platforms.
> > >
> > > Also, since DAVINCI platforms doesn't su
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the TI GPMC as a data bus.
This patch allows an ethernet chip to be defined as an GPMC
child device
The gpmc_probe_nor_child() function is used in the GPMC driver to
configure the GPMC for a NOR child device node.
But this function is quite generic and all the NOR specific configuration
is made by the driver of the actual NOR flash memory used.
Other Pseudo-SRAM devices such as ethernet control
Hello Jon,
As discussed before [1], this patch-set adds DT support for ethernet
controllers connected to a TI GPMC by making gpmc_probe_nor_child()
a generic function and reusing it to initialize "ethernet" child
devices nodes too. It also adds documentation about the DT binding.
The patch-set is
gpmc_probe_nor_child() calls of_platform_device_create() to create a
platform device for the NOR child. If this function fails the value
of ret is returned to the caller but this value is zero since it was
assigned the return of a previous call to gpmc_cs_program_settings()
that had to succeed or o
On Thu, 14 Mar 2013, Felipe Balbi wrote:
> > > if (IS_ERR(phy) || !phy) {
> > > + /* Don't bail out if PHY is not absolutely necessary */
> > > + if (pdata->port_mode[i] != OMAP_EHCI_PORT_MODE_PHY)
> > > + continue;
> > > +
> > >
Salut Jon,
On 03/08/2013 06:27 PM, Jon Hunter wrote:
> Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
>
> The DMA, PMU and OMAP3430 SDP board changes have been sent before
> individually but re-sending here as a complete series for v3.10.
>
> This is based upon v3.9-rc1 an
On Thursday 14 March 2013 07:26 PM, Felipe Balbi wrote:
On Thu, Mar 07, 2013 at 06:51:45PM +0530, Kishon Vijay Abraham I wrote:
From: Graeme Gregory
This is the driver for the OTG transceiver built into the Palmas chip. It
handles the various USB OTG events that can be generated by cable
inser
On Tue, Mar 12, 2013 at 11:57:56AM -0400, Alan Stern wrote:
> On Tue, 12 Mar 2013, Roger Quadros wrote:
>
> > Even when not in PHY mode, the USB device on the port (e.g. HUB)
> > might need resources like RESET which can be modelled as a PHY
> > device. So try to get the PHY device in any case.
>
On Tue, Mar 12, 2013 at 12:25:37PM +0200, Roger Quadros wrote:
> The helper functions omap_usbhs_rev1_hostconfig()
> and omap_usbhs_rev2_hostconfig() don't write into
> the hostconfig register. Make sure that we write
> the return value into the hostconfig register.
>
> Signed-off-by: Roger Quadro
1 - 100 of 138 matches
Mail list logo
