Here are some basic OMAP test results for Linux v3.10.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.10/20130717134228/
Test summary
Build: uImage:
Pass (16/16): am33xx_only, n800_multi_omap2xxx, n800_only_a,
omap1_defconfig, omap1
Hi,
On Friday 19 July 2013 11:59 AM, Greg KH wrote:
> On Fri, Jul 19, 2013 at 11:25:44AM +0530, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Friday 19 July 2013 11:13 AM, Greg KH wrote:
>>> On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay Abraham I wrote:
+ ret = dev_set_name(
On Fri, Jul 19, 2013 at 11:25:44AM +0530, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Friday 19 July 2013 11:13 AM, Greg KH wrote:
> > On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay Abraham I wrote:
> >> + ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);
> >
> > Y
Hi,
On Friday 19 July 2013 11:13 AM, Greg KH wrote:
> On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay Abraham I wrote:
>> +ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);
>
> Your naming is odd, no "phy" anywhere in it? You rely on the sender to
> never s
On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay Abraham I wrote:
> +ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id);
> >>>
> >>> Your naming is odd, no "phy" anywhere in it? You rely on the sender to
> >>> never send a duplicate name.id pair? Why not create your own
Hi,
On Thursday 18 July 2013 09:19 PM, Greg KH wrote:
> On Thu, Jul 18, 2013 at 02:29:52PM +0530, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Thursday 18 July 2013 12:50 PM, Greg KH wrote:
>>> On Thu, Jul 18, 2013 at 12:16:10PM +0530, Kishon Vijay Abraham I wrote:
+struct phy_provider *__of
On Friday 19 July 2013 12:38 AM, Trent Piepho wrote:
On Thu, Jul 18, 2013 at 3:01 AM, Sourav Poddar wrote:
+Required properties:
+- compatible : should be "ti,dra7xxx-qspi".
+- reg: Should contain QSPI registers location and length.
+- #address-cells, #size-cells : Must be present if the device
On Thu, Jul 18, 2013 at 6:39 PM, Santosh Shilimkar
wrote:
> On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote:
>> On 07/18/2013 11:43 AM, Sricharan R wrote:
>>> Some socs have a large number of interrupts/dma requests to service
>>> the needs of its many peripherals and subsystems. All of th
On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote:
> On 07/18/2013 11:43 AM, Sricharan R wrote:
>> Some socs have a large number of interrupts/dma requests to service
>> the needs of its many peripherals and subsystems. All of the
>> requests lines from the subsystems are not needed at the sa
On 07/18/2013 03:39 PM, Mark Brown wrote:
On Thu, Jul 18, 2013 at 12:08:30PM -0700, Trent Piepho wrote:
On Thu, Jul 18, 2013 at 3:01 AM, Sourav Poddar wrote:
+- ti,hwmods: Name of the hwmod associated to the QSPI
What is ti,hwmods? It's not clear from the description. It also
doesn't ap
On Thu, Jul 18, 2013 at 12:08:30PM -0700, Trent Piepho wrote:
> On Thu, Jul 18, 2013 at 3:01 AM, Sourav Poddar wrote:
> > +- ti,hwmods: Name of the hwmod associated to the QSPI
> What is ti,hwmods? It's not clear from the description. It also
> doesn't appear to be used in the driver. At leas
On 07/18/2013 01:36 AM, Tony Lindgren wrote:
> * Stephen Warren [130717 14:30]:
>> On 07/16/2013 03:05 AM, Tony Lindgren wrote:
...
>> Why shouldn't e.g. a pinctrl-based I2C mux also be able to do runtime
>> PM? Does the mux setting select which states are used for runtime PM, or
>> does runtime P
On 07/18/2013 01:25 AM, Tony Lindgren wrote:
> * Stephen Warren [130717 14:21]:
>> On 07/16/2013 03:05 AM, Tony Lindgren wrote:
>>> To toggle dynamic states, let's add the optional active state in
>>> addition to the static default state. Then if the optional active
>>> state is defined, we can re
On Thu, Jul 18, 2013 at 3:01 AM, Sourav Poddar wrote:
> +Required properties:
> +- compatible : should be "ti,dra7xxx-qspi".
> +- reg: Should contain QSPI registers location and length.
> +- #address-cells, #size-cells : Must be present if the device has sub-nodes
> +- ti,hwmods: Name of the hwmod
On 07/18/2013 11:43 AM, Sricharan R wrote:
This adds the irq/dma crossbar device nodes.
There is a IRQ and DMA crossbar device in the soc, which
maps the irq/dma requests from the peripherals to the
mpu/dsp/ipu/eve interrupt and sdma/edma controller's inputs.
The Peripheral irq/dma requests are
On 07/18/2013 12:08 PM, Russell King - ARM Linux wrote:
> On Thu, Jul 18, 2013 at 11:46:39AM -0500, Joel Fernandes wrote:
>> The API is optionally implemented by dmaengine drivers and when
>> unimplemented will return a NULL pointer. A client driver using
>> this API provides the required dma chann
On 07/18/2013 11:43 AM, Sricharan R wrote:
Some socs have a large number of interrupts/dma requests to service
the needs of its many peripherals and subsystems. All of the
requests lines from the subsystems are not needed at the same
time, so they have to be muxed to the controllers appropriately
Hi,
On Thu, Jul 18, 2013 at 10:13:48PM +0530, Sricharan R wrote:
> Some socs have a large number of interrupts/dma requests to service
> the needs of its many peripherals and subsystems. All of the
> requests lines from the subsystems are not needed at the same
> time, so they have to be muxed to
On Thu, Jul 18, 2013 at 11:46:39AM -0500, Joel Fernandes wrote:
> The API is optionally implemented by dmaengine drivers and when
> unimplemented will return a NULL pointer. A client driver using
> this API provides the required dma channel, address width, and
> burst size of the transfer. dma_get_
On 07/18/2013 11:47 AM, Daniel Mack wrote:
> Hi Balaji,
>
> On 18.07.2013 18:40, Balaji T K wrote:
>> With DMA channel info retrieved from dt binding on 3.11rc1,
>> unused_chan_list is broken after hwmod cleanup removing mmc sdma
>> resource info, hence pdev resource wont have DMA resource populat
Hi Balaji,
On 07/18/2013 11:40 AM, Balaji T K wrote:
> On Wednesday 17 July 2013 10:08 PM, Joel Fernandes wrote:
>> On 07/17/2013 10:55 AM, Mark Jackson wrote:
>>> I'm trying to get the MMC port working on our custom AM3352 CPU board.
>>>
>>> I have added MMC entries to out dts file (similar to [1
On Thu, Jul 18, 2013 at 11:46:39AM -0500, Joel Fernandes wrote:
> From: Matt Porter
>
> Add a dmaengine API to retrieve slave SG transfer limits.
>
> The API is optionally implemented by dmaengine drivers and when
> unimplemented will return a NULL pointer. A client driver using
> this API provi
On 07/17/2013 04:54 PM, Laurent Pinchart wrote:
> Hello,
>
> Here's a small patch set that replaces PWM polarity numerical constants with
> macros in DT.
The series,
Reviewed-by: Stephen Warren
I'm (very very) slightly hesitant about patch 3/4, since it's moving
towards all PWMs having to use t
On Thu, 2013-07-18 at 22:13 +0530, Sricharan R wrote:
> Some socs have a large number of interrupts/dma requests to service
> the needs of its many peripherals and subsystems. All of the
> requests lines from the subsystems are not needed at the same
> time, so they have to be muxed to the controll
From: Matt Porter
Add a dmaengine API to retrieve slave SG transfer limits.
The API is optionally implemented by dmaengine drivers and when
unimplemented will return a NULL pointer. A client driver using
this API provides the required dma channel, address width, and
burst size of the transfer. d
From: Matt Porter
The EDMA DMAC has a hardware limitation that prevents supporting
scatter gather lists with any number of segments. The DMA Engine
API reports the maximum number of segments a channel can support
via the optional dma_get_slave_sg_limits() API. If the max_nr_segs
limit is present,
From: Matt Porter
Implement device_slave_sg_limits().
EDMA has a finite set of PaRAM slots available for linking a
multi-segment SG transfer. In order to prevent any one channel
from consuming all PaRAM slots to fulfill a large SG transfer,
the driver reports a static per-channel max number of S
Hi Balaji,
On 18.07.2013 18:40, Balaji T K wrote:
> With DMA channel info retrieved from dt binding on 3.11rc1,
> unused_chan_list is broken after hwmod cleanup removing mmc sdma
> resource info, hence pdev resource wont have DMA resource populated.
>
> arch/arm/common/edma.c
> static int prepare
Some socs have a large number of interrupts/dma requests to service
the needs of its many peripherals and subsystems. All of the
requests lines from the subsystems are not needed at the same
time, so they have to be muxed to the controllers appropriately.
In such places a interrupt/dma controllers
Enable the crossbar driver to handle the irq/dma
crossbar devices in the soc.
Signed-off-by: Sricharan R
---
arch/arm/mach-omap2/Kconfig |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 80aaadc..3def350 100644
--- a/arch/arm/m
Some socs have a large number of interrupts/dma requests to service
the needs of its many peripherals and subsystems. All of the
requests lines from the subsystems are not needed at the same
time, so they have to be muxed to the controllers appropriately.
In such places a interrupt/dma controllers
This adds the irq/dma crossbar device nodes.
There is a IRQ and DMA crossbar device in the soc, which
maps the irq/dma requests from the peripherals to the
mpu/dsp/ipu/eve interrupt and sdma/edma controller's inputs.
The Peripheral irq/dma requests are connected to only one crossbar
input and the
On Wednesday 17 July 2013 10:08 PM, Joel Fernandes wrote:
On 07/17/2013 10:55 AM, Mark Jackson wrote:
I'm trying to get the MMC port working on our custom AM3352 CPU board.
I have added MMC entries to out dts file (similar to [1]), and I've
enabled CONFIG_TI_EDMA.
Our board boots fine without
On Thursday 18 July 2013 09:36 PM, Daniel Mack wrote:
Hi,
I'm facing a NULL pointer dereference in omap_hsmmc_start_command() on
an AM33xx board running 3.11-rc1 (DMA enabled).
A quick debug session showed that DMA engine timing leads to a very
reproducable race condition. In omap_hsmmc_request
Hi,
I'm facing a NULL pointer dereference in omap_hsmmc_start_command() on
an AM33xx board running 3.11-rc1 (DMA enabled).
A quick debug session showed that DMA engine timing leads to a very
reproducable race condition. In omap_hsmmc_request(), we have:
host->mrq = req;
omap_hsmm
On Thu, Jul 18, 2013 at 02:29:52PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Thursday 18 July 2013 12:50 PM, Greg KH wrote:
> > On Thu, Jul 18, 2013 at 12:16:10PM +0530, Kishon Vijay Abraham I wrote:
> >> +struct phy_provider *__of_phy_provider_register(struct device *dev,
> >> + struct m
On Thu, Jul 18, 2013 at 08:25:05PM +0530, Sourav Poddar wrote:
> there is a QSPI_INTR_STATUS_ENABLED_CLEAR register, which indicated
> the interrupt
> status.
> if nothing is set in the above register, I should return IRQ_NONE.
Yes, and/or complain in the log.
signature.asc
Description: Digital
On Thu, Jul 18, 2013 at 03:31:25PM +0530, Sourav Poddar wrote:
> Make spi core calculate the message length while
> populating the other transfer parameters.
Applied, thanks.
signature.asc
Description: Digital signature
There's no need to duplicate essentially the same functions. Let's
introduce static int pinctrl_pm_select_state() and make the other
related functions call that.
This allows us to add support later on for multiple active states,
and more optimized dynamic remuxing.
Note that we still need to expo
To toggle dynamic states, let's add the optional active state in
addition to the static default state. Then if the optional active
state is defined, we can require that idle and sleep states cover
the same pingroups as the active state.
Then let's add pinctrl_check_dynamic() and pinctrl_select_dyn
We want to have static pin states handled separately from
dynamic pin states, so let's add optional state_active.
Then if state_active is defined, let's check and make sure
state_idle and state_sleep match state_active for the
pin groups to avoid checking them during runtime as the
active and idle
It's quite common that we need to dynamically change some pins for a
device for runtime PM, or toggle a pin between rx and tx. Changing all
the pins for a device is not efficient way of doing it.
So let's allow setting up multiple active states for pinctrl. Currently
we only need PINCTRL_STATIC an
Hi all,
Here's this series again with hopefully all the comments addressed.
As discussed earlier, the pinctrl support for changing some of the
consumer device pins during runtime needs some improvment.
Hi Mark,
On Thursday 18 July 2013 08:12 PM, Mark Brown wrote:
On Thu, Jul 18, 2013 at 04:31:58PM +0300, Felipe Balbi wrote:
On Thu, Jul 18, 2013 at 02:18:22PM +0100, Mark Brown wrote:
So why do we report that we handled the interrupt then? Shouldn't we at
least warn if we're getting spurious I
On Thu, Jul 18, 2013 at 04:31:58PM +0300, Felipe Balbi wrote:
> On Thu, Jul 18, 2013 at 02:18:22PM +0100, Mark Brown wrote:
> > So why do we report that we handled the interrupt then? Shouldn't we at
> > least warn if we're getting spurious IRQs?
> not spurious. OMAP has two sets of IRQ status r
* Tony Lindgren [130718 00:57]:
> * Stephen Warren [130717 14:28]:
> >
> > Oh, I see you're trying to check that the set of pins in the active,
> > sleep, and idle states are identical.
>
> Right, that's to avoid any further checking during runtime for runtime PM.
>
> > But I think that pinct
Hi,
On Thu, Jul 18, 2013 at 02:18:22PM +0100, Mark Brown wrote:
> > >>+static irqreturn_t ti_qspi_isr(int irq, void *dev_id)
> > >>+{
> > >>+ struct ti_qspi *qspi = dev_id;
> > >>+ u16 mask, stat;
> > >>+
> > >>+ irqreturn_t ret = IRQ_HANDLED;
> > >>+
> > >>+ spin_lock(&qspi->lock);
> > >>+
> > >>
On Thu, Jul 18, 2013 at 05:15:45PM +0530, Sourav Poddar wrote:
> On Thursday 18 July 2013 04:12 PM, Mark Brown wrote:
> >>+ list_for_each_entry(t,&m->transfers, transfer_list) {
> >>+ qspi->cmd |= QSPI_WLEN(t->bits_per_word);
> >>+ qspi->cmd |= QSPI_WC_CMD_INT_EN;
> >>+
> >>+
On 07/18/2013 03:38 PM, Arend van Spriel wrote:
> On 07/18/2013 01:30 PM, Roger Quadros wrote:
>> On 07/18/2013 02:24 PM, Arend van Spriel wrote:
>>> On 07/18/2013 01:18 PM, Roger Quadros wrote:
Hi Arend,
On 07/18/2013 11:41 AM, Arend van Spriel wrote:
> Hi Tony,
>
>
On 07/18/2013 01:30 PM, Roger Quadros wrote:
On 07/18/2013 02:24 PM, Arend van Spriel wrote:
On 07/18/2013 01:18 PM, Roger Quadros wrote:
Hi Arend,
On 07/18/2013 11:41 AM, Arend van Spriel wrote:
Hi Tony,
We are using the panda board (es variant) for testing our SDIO based chips. For
this
On Thursday 18 July 2013 04:54 PM, Felipe Balbi wrote:
On Thu, Jul 18, 2013 at 04:48:41PM +0530, Sourav Poddar wrote:
+static void qspi_write_msg(struct ti_qspi *qspi, struct spi_transfer *t)
+{
+ const u8 *txbuf;
+ int wlen, count;
+
+ count = t->len;
+ txbuf = t->tx_buf
Hi Tony,
On 07/18/2013 12:04 PM, Tony Lindgren wrote:
* Grygorii Strashko [130718 02:01]:
On 07/18/2013 11:09 AM, Tony Lindgren wrote:
Don't think it's debug code - IO chain need to be rearmed after each
PRCM IO IRQ - otherwise IO wakeup events may be lost (at least on
OMAP4, OMAP5 requires m
Hi,
On Thu, Jul 18, 2013 at 05:15:45PM +0530, Sourav Poddar wrote:
> >>+ list_for_each_entry(t,&m->transfers, transfer_list) {
> >>+ qspi->cmd |= QSPI_WLEN(t->bits_per_word);
> >>+ qspi->cmd |= QSPI_WC_CMD_INT_EN;
> >>+
> >>+ ret = qspi_transfer_msg(qspi, t);
> >>+
On Thursday 18 July 2013 04:14 PM, Mark Brown wrote:
On Thu, Jul 18, 2013 at 03:31:27PM +0530, Sourav Poddar wrote:
Since, qspi controller uses quad read.
Configuring the command register, if the transfer of data needs
dual or quad lines.
This patch has been done on top of the following patch[
On Thursday 18 July 2013 04:12 PM, Mark Brown wrote:
On Thu, Jul 18, 2013 at 03:31:26PM +0530, Sourav Poddar wrote:
QSPI is a kind of spi module that allows single,
dual and quad read access to external spi devices. The module
has a memory mapped interface which provide direct interface
for acc
On 07/18/2013 02:24 PM, Arend van Spriel wrote:
> On 07/18/2013 01:18 PM, Roger Quadros wrote:
>> Hi Arend,
>>
>> On 07/18/2013 11:41 AM, Arend van Spriel wrote:
>>> Hi Tony,
>>>
>>>
>>> We are using the panda board (es variant) for testing our SDIO based chips.
>>> For this we have an adapter car
On Thu, Jul 18, 2013 at 04:48:41PM +0530, Sourav Poddar wrote:
> >>+static void qspi_write_msg(struct ti_qspi *qspi, struct spi_transfer *t)
> >>+{
> >>+ const u8 *txbuf;
> >>+ int wlen, count;
> >>+
> >>+ count = t->len;
> >>+ txbuf = t->tx_buf;
> >>+ wlen = t->bits_per_word;
> >>+
> >>+
On 07/18/2013 01:18 PM, Roger Quadros wrote:
Hi Arend,
On 07/18/2013 11:41 AM, Arend van Spriel wrote:
Hi Tony,
We are using the panda board (es variant) for testing our SDIO based chips. For
this we have an adapter card connection to expansion connector A. As this
adapter is not publicly a
On 07/18/2013 11:14 AM, Tony Lindgren wrote:
* Grygorii Strashko [130717 10:11]:
On 07/17/2013 06:38 PM, Tony Lindgren wrote:
* Grygorii Strashko [130717 04:49]:
Before switching to DT pinctrl states of OMAP IPs have been handled by hwmod
framework. After switching to DT-boot the pinctrl han
Hi Arend,
On 07/18/2013 11:41 AM, Arend van Spriel wrote:
> Hi Tony,
>
>
> We are using the panda board (es variant) for testing our SDIO based chips.
> For this we have an adapter card connection to expansion connector A. As this
> adapter is not publicly available we had internally patched
Hi Felipe,
On Thursday 18 July 2013 03:54 PM, Felipe Balbi wrote:
Hi,
it might be just me, but ...
On Thu, Jul 18, 2013 at 03:31:26PM +0530, Sourav Poddar wrote:
+static inline unsigned long ti_qspi_readl_data(struct ti_qspi *qspi,
+ unsigned long reg, int wlen)
+{
+ switch
Hi Tony, Paul,
On 7/11/2013 12:03 PM, Afzal Mohammed wrote:
AM43x PRCM support (excluding clock tree) is being added with this
series. AM43x reuses most of the IP's from AM335x, as that is the
case, it was felt that reusing AM335x code as much as possible for
AM43x is better - it also helps to
* Tony Lindgren [130718 00:31]:
> * Stephen Warren [130717 14:21]:
> > On 07/16/2013 03:05 AM, Tony Lindgren wrote:
> > > +int pinctrl_check_dynamic(struct device *dev, struct pinctrl_state *st1,
> > > + struct pinctrl_state *st2)
> > > +{
> > > + struct pinctrl_setting *s1, *s2
On Thu, Jul 18, 2013 at 03:31:27PM +0530, Sourav Poddar wrote:
> Since, qspi controller uses quad read.
>
> Configuring the command register, if the transfer of data needs
> dual or quad lines.
>
> This patch has been done on top of the following patch[1], which is just the
> basic idea of addin
On Thu, Jul 18, 2013 at 03:31:26PM +0530, Sourav Poddar wrote:
> QSPI is a kind of spi module that allows single,
> dual and quad read access to external spi devices. The module
> has a memory mapped interface which provide direct interface
> for accessing data form external spi devices.
Have you
Hi,
it might be just me, but ...
On Thu, Jul 18, 2013 at 03:31:26PM +0530, Sourav Poddar wrote:
> +static inline unsigned long ti_qspi_readl_data(struct ti_qspi *qspi,
> + unsigned long reg, int wlen)
> +{
> + switch (wlen) {
> + case 8:
> + return readw(qspi->base
On 07/18/2013 10:59 AM, Tony Lindgren wrote:
* Arend van Spriel [130718 01:47]:
So my first step was to follow the recipe given in that commit.
Beside that I noticed a thread about USB issue on LKML so I also
applied the following commit:
commit 352f573e59050c7a604c35c58b4bbfc51edebbee
Author:
Since, qspi controller uses quad read.
Configuring the command register, if the transfer of data needs
dual or quad lines.
This patch has been done on top of the following patch[1], which is just the
basic idea of adding dual/quad support in spi framework.
$subject patch will undergo changes a
Make spi core calculate the message length while
populating the other transfer parameters.
Usecase, driver can use it to populate framelength filed in their
controller.
Signed-off-by: Sourav Poddar
---
drivers/spi/spi.c |1 +
include/linux/spi/spi.h |1 +
2 files changed, 2 insert
The patch add basic support for the quad spi controller.
QSPI is a kind of spi module that allows single,
dual and quad read access to external spi devices. The module
has a memory mapped interface which provide direct interface
for accessing data form external spi devices.
The patch will configu
Add support for calculating message length in spi framework.
Add support for quad spi controller.
Patch 2 of this series had been posted before. Sending along
with the series along with ather propsed change.
Sourav Poddar (3):
driver: spi: Modify core to compute the message length
drivers: s
On 07/18/2013 10:36 AM, Oleksandr Kozaruk wrote:
> Hello Lars,
>
> On Wed, Jul 17, 2013 at 9:04 PM, Lars-Peter Clausen wrote:
>>> +static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
>>> +{
>>> + int chn, d1 = 0, d2 = 0, temp;
>>> + u8 trim_regs[17];
>>> + int ret;
>>> +
* Grygorii Strashko [130718 02:01]:
> On 07/18/2013 11:09 AM, Tony Lindgren wrote:
>
> Don't think it's debug code - IO chain need to be rearmed after each
> PRCM IO IRQ - otherwise IO wakeup events may be lost (at least on
> OMAP4, OMAP5 requires more complex handling(( ).
Nope, only after the
On Thursday 18 July 2013 12:51 PM, Greg KH wrote:
> On Thu, Jul 18, 2013 at 12:16:11PM +0530, Kishon Vijay Abraham I wrote:
>> Used the generic PHY framework API to create the PHY. Now the power off and
>> power on are done in omap_usb_power_off and omap_usb_power_on respectively.
>>
>> However usi
Hi,
On Thursday 18 July 2013 12:50 PM, Greg KH wrote:
> On Thu, Jul 18, 2013 at 12:16:10PM +0530, Kishon Vijay Abraham I wrote:
>> +struct phy_provider *__of_phy_provider_register(struct device *dev,
>> +struct module *owner, struct phy * (*of_xlate)(struct device *dev,
>> +struct of_phand
* Arend van Spriel [130718 01:47]:
>
> We are using the panda board (es variant) for testing our SDIO based
> chips. For this we have an adapter card connection to expansion
> connector A. As this adapter is not publicly available we had
> internally patched board-omap4panda.c. Also we follow the
We no longer need to model a RESET line as a regulator since
we have the reset-gpio driver available.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap5-uevm.dts | 17 -
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch
Hi,
Till now we were modelling the RESET line as a voltage regulator and
using the regulator framework to manage it.
[1] introduces a GPIO based reset controller driver. We use that
to manage the PHY reset line, at least for DT boots. For legacy boots,
will still need to use the regulator framewo
We no longer need to model a RESET line as a regulator since
we have the reset-gpio driver available.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle.dts | 17 -
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b
On 17/07/13 17:38, Joel Fernandes wrote:
> On 07/17/2013 10:55 AM, Mark Jackson wrote:
>> I'm trying to get the MMC port working on our custom AM3352 CPU board.
>>
>> I have added MMC entries to out dts file (similar to [1]), and I've
>> enabled CONFIG_TI_EDMA.
>>
>> Our board boots fine without an
On 07/18/2013 11:09 AM, Tony Lindgren wrote:
* Grygorii Strashko [130717 09:48]:
Hi,
On 07/17/2013 06:32 PM, Tony Lindgren wrote:
* Grygorii Strashko [130717 04:49]:
Add dynamic "active"/"idle" pin states for uart3/4 which will be applied
when uart3/4 state is switched from active to idle a
Use a common naming scheme "mode0name.modename flags" for the
USB host pins to be consistent.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle.dts | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
Till now we were modelling the RESET line as a voltage regulator and
using the regulator framework to manage it.
[1] introduces a GPIO based reset controller driver. We use that
to manage the PHY reset line, at least for DT boots. For legacy boots,
will still need to use the regulator framework fo
We no longer need to model a RESET line as a regulator since
we have the reset-gpio driver available.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 22 --
1 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-
Provide RESET controller and Power regulator for the USB PHY,
the USB Host port mode and the PHY device. Provide
pin multiplexer information for USB host pins.
We also relocate omap3_pmx_core pin definations so that they
are close to omap3_pmx_wkup pin definations.
Signed-off-by: Roger Quadros
-
Hello Lars,
On Wed, Jul 17, 2013 at 9:04 PM, Lars-Peter Clausen wrote:
>> +static int twl6032_calibration(struct twl6030_gpadc_data *gpadc)
>> +{
>> + int chn, d1 = 0, d2 = 0, temp;
>> + u8 trim_regs[17];
>> + int ret;
>> +
>> + ret = twl_i2c_read(TWL6030_MODULE_ID2, trim_regs + 1
* Grygorii Strashko [130717 10:11]:
> On 07/17/2013 06:38 PM, Tony Lindgren wrote:
> >* Grygorii Strashko [130717 04:49]:
> >>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 fram
* Grygorii Strashko [130717 09:48]:
> Hi,
>
> On 07/17/2013 06:32 PM, Tony Lindgren wrote:
> >* Grygorii Strashko [130717 04:49]:
> >>Add dynamic "active"/"idle" pin states for uart3/4 which will be applied
> >>when uart3/4 state is switched from active to idle and back by Runtime
> >>PM or duri
* Stephen Warren [130717 14:28]:
> On 07/16/2013 03:05 AM, Tony Lindgren wrote:
> > We want to have static pin states handled separately from
> > dynamic pin states, so let's add optional state_active.
> >
> > Then if state_active is defined, let's check and make sure
> > state_idle and state_sle
* Stephen Warren [130717 14:30]:
> On 07/16/2013 03:05 AM, Tony Lindgren wrote:
> > To toggle dynamic states, let's add the optional active state in
> > addition to the static default state. Then if the optional active
> > state is defined, we can require that idle and sleep states cover
> > the s
* Stephen Warren [130717 14:21]:
> On 07/16/2013 03:05 AM, Tony Lindgren wrote:
> > To toggle dynamic states, let's add the optional active state in
> > addition to the static default state. Then if the optional active
> > state is defined, we can require that idle and sleep states cover
> > the s
On Thu, Jul 18, 2013 at 12:16:11PM +0530, Kishon Vijay Abraham I wrote:
> Used the generic PHY framework API to create the PHY. Now the power off and
> power on are done in omap_usb_power_off and omap_usb_power_on respectively.
>
> However using the old USB PHY library cannot be completely removed
On Thu, Jul 18, 2013 at 12:16:10PM +0530, Kishon Vijay Abraham I wrote:
> +struct phy_provider *__of_phy_provider_register(struct device *dev,
> + struct module *owner, struct phy * (*of_xlate)(struct device *dev,
> + struct of_phandle_args *args));
> +struct phy_provider *__devm_of_phy_pro
* Kishon Vijay Abraham I [130717 23:53]:
> Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
> binding in order for the driver to use the new generic PHY framework.
> Also updated the Documentation to include the binding information.
> The PHY binding information can be found at
* Kishon Vijay Abraham I [130717 23:53]:
> In order for controllers to get PHY in case of non dt boot, the phy
> binding information (phy device name) should be added in the platform
> data of the controller.
>
> Signed-off-by: Kishon Vijay Abraham I
> Reviewed-by: Sylwester Nawrocki
> Acked-by
95 matches
Mail list logo
