On Fri, Jun 21, 2013 at 7:07 PM, Joel A Fernandes wrote:
> Hi Sekhar,
>
> On Fri, Jun 21, 2013 at 5:27 AM, Sekhar Nori wrote:
>> Joel,
>>
>> On 6/21/2013 2:36 AM, Joel A Fernandes wrote:
>>> From: Joel A Fernandes
>>>
>>> This series is remaining of Matt Porter's EDMA patches for AM33XX EDMA
>>
Fixup for linux-davinci/soc-v2 branch. Please ignore v1 and use this.
Returning a pointer to a variable in the setup_from_dt function is
causing dangling pointer dereferences. This causes boot to fail
on AM33XX.
Add ninfo to the caller's stack and just return the kzalloc'ed ptr
from the calling fu
>> > config TI_EDMA
>> > tristate "TI EDMA support"
>> > default m if 'ARCH_DAVINCI || ARCH_OMAP1 || ARCH_OMAP2
>> > select DMA_ENGINE
>> > select DMA_VIRTUAL_CHANNELS
>>
>>
>> MMC depends on EDMA specially on AM33xx there's no PIO mode AFAIK. The
>> 'm' option will
Hi Sekhar,
On Fri, Jun 21, 2013 at 5:27 AM, Sekhar Nori wrote:
> Joel,
>
> On 6/21/2013 2:36 AM, Joel A Fernandes wrote:
>> From: Joel A Fernandes
>>
>> This series is remaining of Matt Porter's EDMA patches for AM33XX EDMA
>> support
>> with changes for few pending review comments on v11 serie
Returning a pointer to a variable in the setup_from_dt function is
causing dangling pointer dereferences. This causes boot to fail
on AM33XX.
Add ninfo to the caller's stack and just return the kzalloc'ed ptr
from the calling function.
Seen on linux-davinci/soc-v2 branch.
Cc: Sekhar Nori
Signed
With am43xx enabled, omap4 and omap5 disabled and SMP on, I get these
build errors:
arch/arm/mach-omap2/built-in.o: In function `scu_gp_set':
:(.text+0x7858): undefined reference to `omap4_get_scu_base'
arch/arm/mach-omap2/built-in.o: In function `scu_gp_clear':
:(.text+0x793c): undefined referenc
When an OMAP GPIO is used as an IRQ line, a call to gpio_request()
has to be made to initialize the OMAP GPIO bank before a driver
request the IRQ. Otherwise the call to request_irq() fails.
Drives should not be aware of this neither care wether an IRQ line
is a GPIO or not. They should just reque
When a GPIO is defined as an interrupt line using Device
Tree, a call to irq_create_of_mapping() is made that calls
irq_create_mapping(). So, is not necessary to do the mapping
on the OMAP GPIO platform_driver and in fact is wrong to
assume that all GPIO lines will be used as an IRQ.
Add a custom
When an OMAP GPIO is used as an IRQ line, a call to gpio_request()
has to be made to initialize the OMAP GPIO bank before a driver
request the IRQ. Otherwise the call to request_irq() fails.
Drivers should not be aware of this neither care wether an IRQ line
is a GPIO or not. They should just requ
On Friday 21 June 2013, Joel A Fernandes wrote:
> Hi Arnd,
>
> On Fri, Jun 21, 2013 at 1:44 PM, Arnd Bergmann wrote:
> > On Friday 21 June 2013, Joel A Fernandes wrote:
> >> I think we are talking about different things, I agree the 'select
> >> DMADEVICES' can be dropped but lets please keep the
Hi Arnd,
On Fri, Jun 21, 2013 at 1:44 PM, Arnd Bergmann wrote:
> On Friday 21 June 2013, Joel A Fernandes wrote:
>> I think we are talking about different things, I agree the 'select
>> DMADEVICES' can be dropped but lets please keep the default y option
>> (not adding new select statements, just
OMAP443x, OMAP446x SoC use same offsets for voltage processor,
however their voltage characteristics differ a little.
Introduce the voltage processor nodes for the same.
Signed-off-by: Nishanth Menon
---
arch/arm/boot/dts/omap4.dtsi| 43 +++
arch/arm/bo
OMAP4430 and 4460 platforms use TWL6030 to power voltage rails.
However, on 4460, we use twl6030 only for iva and core voltage rails.
Introduce an twl6030_omap4.dtsi to be able to reuse the base definition
for all OMAP4 platforms and the delta change only for panda-es platform
which is based on 44
OMAP443x, OMAP446x SoC use same offsets for voltage controller,
however their voltage characteristics differ a little.
Introduce the voltage controller nodes for the same.
Signed-off-by: Nishanth Menon
---
arch/arm/boot/dts/omap4.dtsi| 26 ++
arch/arm/boot/dts/omap
Unlike other OMAP4 platforms including the the "vanilla" PandaBoard,
PandaBoard-ES uses TPS62361 to supply vdd_mpu.
Signed-off-by: Nishanth Menon
---
arch/arm/boot/dts/omap4-panda-es.dts | 18 ++
arch/arm/boot/dts/tps62361_omap.dtsi | 18 ++
2 files changed, 3
Texas Instrument's OMAP SoC generations since OMAP3-5 introduced
an TI custom hardware block to better facilitate and standardize
integration of Power Management ICs which communicate over I2C.
In fact, many custom PMICs were designed to be usable over this
interface. On the other hand, generic PM
Hi,
Texas Instrument's OMAP Processor have a dedicated hardware module
which is customised to operate with Power Management IC(PMIC) over an dedicated
I2C. The communication involves a few SoC internal modules as follows:
PMIC - The power management chip on the dedicated I2C (sometimes called I2C_
Texas Instrument's OMAP SoC generations since OMAP3-5 introduced an TI
custom hardware block to better facilitate and standardize integration
of Power Management ICs which communicate over I2C called Voltage
Processor(VP).
This is an specialized hardware block meant to support PMIC chips only
over
Texas Instrument's OMAP SoC generations since OMAP3-5 introduced an TI
custom hardware block to better facilitate and standardize integration
of Power Management ICs which communicate over I2C called Voltage
Controller(VC).
This is an specialized hardware block meant to support PMIC chips and
is c
TPS62361 is used for cpufreq regulation. As part of this change
use labels that can be used to reference cpu0 to setup it's supply.
Signed-off-by: Nishanth Menon
---
arch/arm/boot/dts/omap4-panda-es.dts |4
arch/arm/boot/dts/omap4.dtsi |4 ++--
arch/arm/boot/dts/omap443x.dts
On 22:29-20130621, Arnd Bergmann wrote:
> Building OMAP5 support without this file currently results in this link error:
>
> arch/arm/mach-omap2/built-in.o: In function `omap54xx_voltagedomains_init':
> :(.init.text+0x6b80): undefined reference to `omap446x_vdd_core_volt_dat
Building OMAP5 support without this file currently results in this link error:
arch/arm/mach-omap2/built-in.o: In function `omap54xx_voltagedomains_init':
:(.init.text+0x6b80): undefined reference to `omap446x_vdd_core_volt_data'
:(.init.text+0x6b84): undefined reference to `omap446x_vdd_mpu_volt_
On Friday 21 June 2013, Joel A Fernandes wrote:
> I think we are talking about different things, I agree the 'select
> DMADEVICES' can be dropped but lets please keep the default y option
> (not adding new select statements, just saying that if someone select
> DMADEVICES in menuconfig and if they'
On Fri, Jun 21, 2013 at 9:32 AM, Arnd Bergmann wrote:
> On Friday 21 June 2013, Joel A Fernandes wrote:
>> I haven't come across this problem but- are you saying there is a
>> shortcoming in Kbuild/Kconfig that selects an option even if its
>> dependency is not met?
>
> Well, the shortcoming is th
Addition of the M and N recommended values for the USB3 PHY DPLL.
Sysclk for DRA7xx is 20MHz.
This yields:
Clk = 20MHz * M/(N+1) = 20MHz * 1000 /(7+1) = 2.5 Ghz
Signed-off-by: Nikhil Devshatwar
Signed-off-by: Ruchika Kharwar
---
drivers/usb/phy/phy-omap-usb3.c |7 ++-
1 file changed, 6
Before switching to DT pinctrl states of OMAP IPs have been handled by hwmod
framework. After switching to DT-boot the pinctrl handling was dropped from
hwmod framework and, as it was recommended, OMAP IP's drivers have to be updated
to handle pinctrl states by itself using pinctrl_pm_select_xx() h
On Friday 21 June 2013, Joel A Fernandes wrote:
> I haven't come across this problem but- are you saying there is a
> shortcoming in Kbuild/Kconfig that selects an option even if its
> dependency is not met?
Well, the shortcoming is that it lets you specify impossible
contraints. You get a warning
On Fri, Jun 21, 2013 at 07:43:55AM -0500, Nishanth Menon wrote:
> On 10:51-20130621, Mark Brown wrote:
> > No, the consumer really doesn't want to be aware of linear step
> > regulators. Why would it care that there even are linear steps? If
> > the consumer
On Fri, Jun 21, 2013 at 9:00 AM, Arnd Bergmann wrote:
> On Friday 21 June 2013, Joel A Fernandes wrote:
>> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> >> index b1c66a4..7d58cd9 100644
>> >> --- a/arch/arm/Kconfig
>> >> +++ b/arch/arm/Kconfig
>> >> @@ -841,6 +841,7 @@ config ARCH_DAVINCI
On Friday 21 June 2013, Joel A Fernandes wrote:
> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >> index b1c66a4..7d58cd9 100644
> >> --- a/arch/arm/Kconfig
> >> +++ b/arch/arm/Kconfig
> >> @@ -841,6 +841,7 @@ config ARCH_DAVINCI
> >> select HAVE_IDE
> >> select NEED_MACH_GPIO_H
On Fri, Jun 21, 2013 at 5:16 AM, Sekhar Nori wrote:
> On 6/21/2013 2:36 AM, Joel A Fernandes wrote:
>> From: Joel A Fernandes
>>
>> Build TI_EDMA by default for ARCH_DAVINCI and ARCH_OMAP2PLUS
>>
>> Signed-off-by: Joel A Fernandes
>
> You should sign-off with author e-mail address.
>
>> ---
>>
On Fri, Jun 21, 2013 at 4:37 AM, Sekhar Nori wrote:
> Joel,
>
> Looks like you have not addressed all comments from last time.
> For now, in the interest of time, I have fixed them myself. But next
> time on, if you are not going to fix any comment, then please reply
> upfront before sending out *
On 17:57-20130620, Mike Turquette wrote:
> On Wed, Jun 19, 2013 at 6:18 AM, Tero Kristo wrote:
> > of_property_read_u8 does not work properly because of endianess problem
> > with its current implementation, and this causes it to always return
> > 0 with little endian architectures. Instead, use p
On 10:51-20130621, Mark Brown wrote:
> On Thu, Jun 20, 2013 at 07:45:42AM -0500, Nishanth Menon wrote:
> > On 23:38-20130619, Mark Brown wrote:
>
> > > If the consumer can tolerate a different voltage why not just request
> > > the range that can be tolerated? Your
Hi Mark,
On Friday 21 June 2013 04:58 PM, Mark Brown wrote:
On Fri, Jun 21, 2013 at 04:07:51PM +0530, Sekhar Nori wrote:
We can resend the patch if you don't have it from the mailing list.
I'll probably have it assuming it's been sent to some mailing list I
read (the CC list here looks absurld
Modified dwc3-omap to receive connect and disconnect notification using
extcon framework. Also did the necessary cleanups required after
adapting to extcon framework.
Signed-off-by: Kishon Vijay Abraham I
Acked-by: Felipe Balbi
Acked-by: Chanwoo Choi
---
This patch should be applied after all o
On Fri, Jun 21, 2013 at 04:07:51PM +0530, Sekhar Nori wrote:
> We can resend the patch if you don't have it from the mailing list.
I'll probably have it assuming it's been sent to some mailing list I
read (the CC list here looks absurldy large...) but if you don't send me
the patch and/or ignore
Fixing Mark's e-mail.
Mark,
On 6/21/2013 3:56 PM, Sourav Poddar wrote:
> Hi Mark,
> On Friday 21 June 2013 02:36 AM, Joel A Fernandes wrote:
>> From: Matt Porter
>>
>> Convert dmaengine channel requests to use
>> dma_request_slave_channel_compat(). This supports the DT case of
>> platforms requi
Hi Benoit,
On Friday 21 June 2013 02:36 AM, Joel A Fernandes wrote:
From: Matt Porter
The binding definition is based on the generic DMA request binding
Signed-off-by: Matt Porter
Signed-off-by: Joel A Fernandes
---
Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +++
Joel,
On 6/21/2013 2:36 AM, Joel A Fernandes wrote:
> From: Joel A Fernandes
>
> This series is remaining of Matt Porter's EDMA patches for AM33XX EDMA support
> with changes for few pending review comments on v11 series.
I have posted a branch with fixes for patches accepted by me in this
seri
Hi Mark,
On Friday 21 June 2013 02:36 AM, Joel A Fernandes wrote:
From: Matt Porter
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from
On 6/21/2013 2:36 AM, Joel A Fernandes wrote:
> From: Joel A Fernandes
>
> Build TI_EDMA by default for ARCH_DAVINCI and ARCH_OMAP2PLUS
>
> Signed-off-by: Joel A Fernandes
You should sign-off with author e-mail address.
> ---
> arch/arm/Kconfig|1 +
> arch/arm/mach-omap2/Kcon
From: Matt Porter
EDMA supports a cross bar which provides ability
to mux additional events into physical channels
present in the channel controller.
This is required when the number of events present
in the system are more than number of available
physical channels.
Changes by Joel:
* Split ED
On 6/21/2013 2:36 AM, Joel A Fernandes wrote:
> From: Matt Porter
>
> Enable TI EDMA option on OMAP and TI_PRIV_EDMA
>
> Signed-off-by: Matt Porter
> Signed-off-by: Joel A Fernandes
This will have to be taken by Tony.
Thanks,
Sekhar
> ---
> arch/arm/mach-omap2/Kconfig |1 +
> drivers/d
On 6/21/2013 2:36 AM, Joel A Fernandes wrote:
> From: Matt Porter
>
>
You should add a description apart from just documenting what you
changed in this patch.
Changes by Joel:
> * Split EDMA xbar support out of original EDMA DT parsing patch
> to keep it easier for review.
> * Rewrite shift an
From: Matt Porter
Adds support for parsing the TI EDMA DT data into the required EDMA
private API platform data. Enables runtime PM support to initialize
the EDMA hwmod. Enables build on OMAP.
Changes by Joel:
* Setup default one-to-one mapping for queue_priority and queue_tc
mapping as discusse
On Thu, Jun 20, 2013 at 07:45:42AM -0500, Nishanth Menon wrote:
> On 23:38-20130619, Mark Brown wrote:
> > If the consumer can tolerate a different voltage why not just request
> > the range that can be tolerated? Your problem here is specifying an
> > exact voltage.
> I think you mean using reg
Joel,
Looks like you have not addressed all comments from last time.
For now, in the interest of time, I have fixed them myself. But next
time on, if you are not going to fix any comment, then please reply
upfront before sending out *any* new versions.
Also, *please* run checkpatch and fix all bu
Hi Samuel,
> -Original Message-
> From: J, KEERTHY
> Sent: Thursday, June 20, 2013 4:32 PM
> To: linux-omap@vger.kernel.org; sa...@linux.intel.com
> Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com;
> grant.lik...@secretlab.ca; swar...@nvidia.com; linux-
> ker...@vger.kernel.org; l
Hello Samuel,
> -Original Message-
> From: J, KEERTHY
> Sent: Thursday, June 20, 2013 4:35 PM
> To: linux-omap@vger.kernel.org; sa...@linux.intel.com
> Cc: broo...@kernel.org; J, KEERTHY; ldewan...@nvidia.com;
> grant.lik...@secretlab.ca; swar...@nvidia.com; linux-
> ker...@vger.kernel.org
On 06/21/2013 03:42 AM, Javier Martinez Canillas wrote:
> When an OMAP GPIO is used as an IRQ line, a call to gpio_request()
> has to be made to initialize the OMAP GPIO bank before a driver
> request the IRQ. Otherwise the call to request_irq() fails.
>
> Drives should not be aware of this neithe
Do a release_mem_region of the hcd resource. Without this the
subsequent insertion of module fails in request_mem_region.
Signed-off-by: George Cherian
---
drivers/usb/host/xhci-plat.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
On 5/31/2013 1:24 AM, Ruchika Kharwar wrote:
Addition of the M and N recommended values for the USB3 PHY DPLL.
Sysclk for DRA7xx is 20MHz.
This yields:
Clk = 20MHz * M/(N+1) = 20MHz * 1000 /(7+1) = 2.5 Ghz
Signed-off-by: Ruchika Kharwar
---
drivers/usb/phy/phy-omap-usb3.c |7 ++-
1 f
On Friday 21 June 2013, Anna, Suman wrote:
> Yes, we still have a plan for a generic subsystem, and these would form the
> the base patches of OMAP adaptation towards that. OMAP mailbox was disabled
> since couple of releases now because of the multi-platform enablement. There
> were
> couple of d
* Tero Kristo [130619 06:25]:
> Some of the clock.h contents are needed by the new OMAP clock driver,
> including dpll_data and clk_hw_omap. Thus, move these to the generic
> omap header file which can be accessed by the driver.
Do you mean "are only needed by the new OMAP clock driver"?
Otherwi
* Tero Kristo [130619 06:25]:
> Now that the OMAP4 PRCM clock data has been converted to device tree
> representation, it is no longer needed as static clock data. OMAP4
> clock init routine is also changed to register DT clocks first.
>
> Signed-off-by: Tero Kristo
> ---
> arch/arm/mach-omap2/
56 matches
Mail list logo
