[PATCH v2 1/1] net: ethernet: davinci_cpdma: Add boundary for rx and tx descriptors
When there is heavy transmission traffic in the CPDMA, then Rx descriptors
memory is also utilized as tx desc memory looses all rx descriptors and the
driver stops working then.
This patch adds boundary for tx and rx descriptors in bd ram dividing the
descriptor memory to ensure that during heavy transmission tx doesn't use
rx descriptors.
This patch is already applied to davinci_emac driver, since CPSW and
davici_dmac shares the same CPDMA, moving the boundry seperation from
Davinci EMAC driver to CPDMA driver which was done in the following
commit
commit 86d8c07ff2448eb4e860e50f34ef6ee78e45c40c
Author: Sascha Hauer
Date: Tue Jan 3 05:27:47 2012 +
net/davinci: do not use all descriptors for tx packets
The driver uses a shared pool for both rx and tx descriptors.
During open it queues fixed number of 128 descriptors for receive
packets. For each received packet it tries to queue another
descriptor. If this fails the descriptor is lost for rx.
The driver has no limitation on tx descriptors to use, so it
can happen during a nmap / ping -f attack that the driver
allocates all descriptors for tx and looses all rx descriptors.
The driver stops working then.
To fix this limit the number of tx descriptors used to half of
the descriptors available, the rx path uses the other half.
Tested on a custom board using nmap / ping -f to the board from
two different hosts.
Signed-off-by: Mugunthan V N
---
Changes from initial patch:
* Modified commit message with proper description as in previous commit message
drivers/net/ethernet/ti/davinci_cpdma.c | 20 ++--
drivers/net/ethernet/ti/davinci_emac.c |8
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c
b/drivers/net/ethernet/ti/davinci_cpdma.c
index 4995673..d37f546 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -105,13 +105,13 @@ struct cpdma_ctlr {
};
struct cpdma_chan {
+ struct cpdma_desc __iomem *head, *tail;
+ void __iomem*hdp, *cp, *rxfree;
enum cpdma_statestate;
struct cpdma_ctlr *ctlr;
int chan_num;
spinlock_t lock;
- struct cpdma_desc __iomem *head, *tail;
int count;
- void __iomem*hdp, *cp, *rxfree;
u32 mask;
cpdma_handler_fnhandler;
enum dma_data_direction dir;
@@ -217,7 +217,7 @@ desc_from_phys(struct cpdma_desc_pool *pool, dma_addr_t dma)
}
static struct cpdma_desc __iomem *
-cpdma_desc_alloc(struct cpdma_desc_pool *pool, int num_desc)
+cpdma_desc_alloc(struct cpdma_desc_pool *pool, int num_desc, bool is_rx)
{
unsigned long flags;
int index;
@@ -225,8 +225,14 @@ cpdma_desc_alloc(struct cpdma_desc_pool *pool, int
num_desc)
spin_lock_irqsave(&pool->lock, flags);
- index = bitmap_find_next_zero_area(pool->bitmap, pool->num_desc, 0,
- num_desc, 0);
+ if (is_rx) {
+ index = bitmap_find_next_zero_area(pool->bitmap,
+ pool->num_desc/2, 0, num_desc, 0);
+} else {
+ index = bitmap_find_next_zero_area(pool->bitmap,
+ pool->num_desc, pool->num_desc/2, num_desc, 0);
+ }
+
if (index < pool->num_desc) {
bitmap_set(pool->bitmap, index, num_desc);
desc = pool->iomap + pool->desc_size * index;
@@ -660,6 +666,7 @@ int cpdma_chan_submit(struct cpdma_chan *chan, void *token,
void *data,
unsigned long flags;
u32 mode;
int ret = 0;
+ boolis_rx;
spin_lock_irqsave(&chan->lock, flags);
@@ -668,7 +675,8 @@ int cpdma_chan_submit(struct cpdma_chan *chan, void *token,
void *data,
goto unlock_ret;
}
- desc = cpdma_desc_alloc(ctlr->pool, 1);
+ is_rx = (chan->rxfree != 0);
+ desc = cpdma_desc_alloc(ctlr->pool, 1, is_rx);
if (!desc) {
chan->stats.desc_alloc_fail++;
ret = -ENOMEM;
diff --git a/drivers/net/ethernet/ti/davinci_emac.c
b/drivers/net/ethernet/ti/davinci_emac.c
index fce89a0..f349273 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -120,7 +120,6 @@ static const char emac_version_string[] = "TI DaVinci EMAC
Linux v6.1";
#define EMAC_DEF_TX_CH (0) /* Default 0th channel */
#define EMAC_DEF_RX_CH (0) /* Default 0th channel */
#define EMAC_DEF_RX_NUM_DESC (128)
-#define EMAC_DEF_TX_NUM_DESC (128)
#define EMAC_DEF_MAX_TX_CH
Re: [PATCH 1/8] ARM: OMAP2+: PM QoS: control the power domains next state from the constraints
Hi
On Tue, 18 Sep 2012, Jean Pihet wrote:
> When a PM QoS device latency constraint is requested or removed the
> constraint is stored in the constraints list of the corresponding power
> domain, then the aggregated constraint value is applied by programming
> the next functional power state using pwrdm_set_fpwrst.
>
> The per-device PM QoS locking requires a spinlock to be used. The reasons
> is that some drivers need to use the per-device PM QoS functionality from
> interrupt context or spinlock protected context, as reported by Djamil.
> An example of such a driver is the OMAP HSI (high-speed synchronous serial
> interface) driver which needs to control the IP block idle state from
> the FIFO empty state, from interrupt context.
>
> Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using
> wake-up latency constraints on MPU, CORE and PER.
>
> Signed-off-by: Jean Pihet
> Cc: Djamil Elaidi
This patch has been changed here. Details below, but the major changes
were to fix the locking and to not attempt GFP_ATOMIC allocations.
Hopefully the reasons why are clear, but if not, feel free to ask.
The following patch has only been compile-tested, and a few more minor
changes will probably be needed.
- Paul
From: Jean Pihet
Date: Sun, 9 Dec 2012 18:38:12 -0700
Subject: [PATCH] ARM: OMAP2+: PM QoS: control the power domains next state
from the constraints
When a PM QoS device latency constraint is requested or removed the
constraint is stored in the constraints list of the corresponding power
domain, then the aggregated constraint value is applied by programming
the next functional power state using pwrdm_set_fpwrst.
The per-device PM QoS locking requires a spinlock to be used. The reasons
is that some drivers need to use the per-device PM QoS functionality from
interrupt context or spinlock protected context, as reported by Djamil.
An example of such a driver is the OMAP HSI (high-speed synchronous serial
interface) driver which needs to control the IP block idle state from
the FIFO empty state, from interrupt context.
Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using
wake-up latency constraints on MPU, CORE and PER.
Signed-off-by: Jean Pihet
Cc: Djamil Elaidi
[p...@pwsan.com: updated to apply; renamed *state to *fpwrst and
define as u8; use existing powerdomain spinlock; pack the struct powerdomain
variables; removed the GFP_ATOMIC allocation; drop expensive operations
from the _pwrdm_wakeuplat_update_pwrst() debug; ensure that the entire
wakeuplat update process takes place under the spinlock; remove
UNSUP_STATE; remove assumption that fpwrsts start at 0; remove
unnecessary plist_empty test from update path; standardize 'wakeuplat'
naming; add kerneldoc]
XXX conform debug to other powerdomain debugging
---
arch/arm/mach-omap2/powerdomain.c | 208 +
arch/arm/mach-omap2/powerdomain.h | 27 -
2 files changed, 233 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 7caceaa..bcba0af 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -21,8 +21,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -125,6 +127,9 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
for (i = 0; i < PWRDM_FPWRSTS_COUNT; i++)
pwrdm->fpwrst_counter[i] = 0;
+ plist_head_init(&pwrdm->wakeuplat_plist_head);
+ pwrdm->wakeuplat_next_fpwrst = PWRDM_FUNC_PWRST_OFF;
+
arch_pwrdm->pwrdm_wait_transition(pwrdm);
pwrdm->fpwrst = pwrdm_read_fpwrst(pwrdm);
pwrdm->fpwrst_counter[pwrdm->fpwrst - PWRDM_FPWRST_OFFSET] = 1;
@@ -765,6 +770,58 @@ static int _pwrdm_set_fpwrst(struct powerdomain *pwrdm,
return ret;
}
+/**
+ * _pwrdm_wakeuplat_update_pwrst - Update power domain power state if needed
+ * @pwrdm: struct powerdomain * to which requesting device belongs to.
+ * @min_latency: the allowed wake-up latency for the given power domain. A
+ * value of PM_QOS_DEV_LAT_DEFAULT_VALUE means 'no constraint' on the pwrdm.
+ *
+ * Finds the power domain next power state that fulfills the constraint.
+ * Programs a new target state if it is different from current power state.
+ * The power domains get the next power state programmed directly in the
+ * registers.
+ *
+ * Must be called with the powerdomain lock held.
+ *
+ * Returns 0 in case of success, -EINVAL in case of invalid parameters,
+ * or the return value from _pwrdm_set_fpwrst().
+ */
+static int _pwrdm_wakeuplat_update_pwrst(struct powerdomain *pwrdm,
+long min_latency)
+{
+ int ret = 0, new_fpwrst = PWRDM_FUNC_PWRST_ON;
+ int fpwrst, pwl_index;
+
+ /*
+* Find the next supported power state with
+* wakeup latency <= min_latency.
+* Pick the lower state if no constraint on the p
[PATCH] usb: dwc3: debugfs: fix regdump offset
As with dwc_readl/writel, the global registers are specified as
offsets starting from the beginning of the xHCI address space,
but the memory region pointed to by dwc->regs already maps to
the start of the global addresses. Fix by offsetting each of the
regs relative to DWC3_GLOBALS_REGS_START.
Signed-off-by: Jack Pham
---
drivers/usb/dwc3/debugfs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index d4a30f1..be4eff7 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -56,7 +56,7 @@
#define dump_register(nm) \
{ \
.name = __stringify(nm), \
- .offset = DWC3_ ##nm, \
+ .offset = DWC3_ ##nm - DWC3_GLOBALS_REGS_START, \
}
static const struct debugfs_reg32 dwc3_regs[] = {
--
Employee of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: timer: remove CONFIG_OMAP_32K_TIMER
On Sun, 11 Nov 2012, Igor Grinberg wrote: > Yep, but the /800 do not get you the 32768... > and that makes the timer suck. > Of course this can be dealt with in the clock subsystem > (I remember Paul said that he will look into that), but it will take time. It should be possible to implement this now that the CCF conversion is done. Not sure if I'll be able to get to it soon, though. Is there anyone out there at TI who is focused on AM3517/3505 upstream work? - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM335x BeagleBone SPI Issues
Hi,
On Mon, Dec 10, 2012 at 03:19:15PM +, Jack Mitchell wrote:
> On 10/12/12 14:59, Felipe Balbi wrote:
> >Hi,
> >
> >On Mon, Dec 10, 2012 at 02:50:16PM +, Jack Mitchell wrote:
> >>>On Mon, Dec 10, 2012 at 01:23:09PM +, Jack Mitchell wrote:
> Hi,
>
> I am currently having issues with the SPI driver on the beaglebone
> using the 3.7-rc8 kernel[1]. I have probed the SPI pins and I have
> found that writing works however reading doesn't. When using DMA the
> program seems to lock hard and no data is sent on the bus. I am
> testing the bus using spidev and the spidev_test[2] application,
> however I first came across spi issues with a custom spi driver which
> stopped working when I transitioned from 3.2-psp to 3.7-rc8.
>
> The current output I am seeing from the spidev_test program is just a
> series of 0x00 data, which looks to me like no data is getting in at
> all. The spidev_test program is not using DMA as the buffer size is
> too low, so I forced the dma on when buffer size is > 1 and the
> program hangs hard with the system still responding to other
> commands.I have briged the pins 18 and 21 on the BeagleBone P9
> header.
>
> Has anyone seen issues like this, or if not if someone could please
> test the latest 3.7-rc8 from [1] and let me know if it works for them
> and the issue is at my end.
>
> To get spidev working with devicetree I applied the patch from [3]
> and changed the dtb as in the patch pasted below.
>
> [1] https://github.com/beagleboard/kernel/tree/3.7
> [2] http://lxr.linux.no/#linux+v3.6.9/Documentation/spi/spidev_test.c
> [3]
> http://www.mail-archive.com/spi-devel-general@lists.sourceforge.net/msg09958.html
> >>>do you have any debugging output from that driver ? It would be cool to
> >>>see if DMA is at least being kicked properly for small transfers.
> >>When I run the spidev program with dma for transfers > 1, the program
> >>hangs and the only output in dmesg is:
> >>
> >>[ 12.613952] libphy: 4a101000.mdio:00 - Link is Up - 100/Full <
> >>Last line from initial log in [2]
> >>[ 47.669202] spidev spi1.0: setup: speed 2400, sample leading
> >>edge, clk normal
> >>[ 47.669246] spidev spi1.0: setup mode 0, 8 bits/w, 2400 Hz max --> 0
> >>[ 47.669260] spidev spi1.0: spi mode 00
> >>[ 47.669283] spidev spi1.0: setup: speed 2400, sample leading
> >>edge, clk normal
> >>[ 47.669300] spidev spi1.0: setup mode 0, 16 bits/w, 2400 Hz max --> 0
> >>[ 47.669312] spidev spi1.0: 16 bits per word
> >>[ 47.669330] spidev spi1.0: setup: speed 2400, sample leading
> >>edge, clk normal
> >>[ 47.669347] spidev spi1.0: setup mode 0, 16 bits/w, 2400 Hz max --> 0
> >>[ 47.669358] spidev spi1.0: 2400 Hz (max)
> >>[ 47.673811] spidev spi1.0: setup: speed 2400, sample leading
> >>edge, clk normal
> >>
> >>The initial dmesg statup log is at [2].
> >can you apply the debugging patch below to spi driver and show me the
> >output again ?
> >
> >Note that I'm allowing DMA for as small as 1-byte transfers (as you
> >needed) and I'm also disabling DMA Request line before calling
> >complete() as I think the current way could race, but likely wouldn't
> >cause issues. Anyway, please show me the output.
> >
> >diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
> >index 3542fdc..d2b1af2 100644
> >--- a/drivers/spi/spi-omap2-mcspi.c
> >+++ b/drivers/spi/spi-omap2-mcspi.c
> >@@ -108,7 +108,7 @@ struct omap2_mcspi_dma {
> > /* use PIO for small transfers, avoiding DMA setup/teardown overhead and
> > * cache operations; better heuristics consider wordsize and bitrate.
> > */
> >-#define DMA_MIN_BYTES 160
> >+#define DMA_MIN_BYTES 1
> > /*
> >@@ -298,10 +298,11 @@ static void omap2_mcspi_rx_callback(void *data)
> > struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master);
> > struct omap2_mcspi_dma *mcspi_dma =
> > &mcspi->dma_channels[spi->chip_select];
> >-complete(&mcspi_dma->dma_rx_completion);
> >-
> > /* We must disable the DMA RX request */
> >+dev_info(&spi->dev, "Disabling RX Request Line\n");
> > omap2_mcspi_set_dma_req(spi, 1, 0);
> >+
> >+complete(&mcspi_dma->dma_rx_completion);
> > }
> > static void omap2_mcspi_tx_callback(void *data)
> >@@ -310,10 +311,11 @@ static void omap2_mcspi_tx_callback(void *data)
> > struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master);
> > struct omap2_mcspi_dma *mcspi_dma =
> > &mcspi->dma_channels[spi->chip_select];
> >-complete(&mcspi_dma->dma_tx_completion);
> >-
> > /* We must disable the DMA TX request */
> >+dev_info(&spi->dev, "Disabling TX Request Line\n");
> > omap2_mcspi_set_dma_req(spi, 0, 0);
> >+
> >+complete(&mcspi_dma->dma_tx_completion);
> > }
> > static void omap2_mcspi_tx_dma(struct spi_device *spi,
> >@@ -328,6 +330,7 @@
Re: [PATCH v4 22/23] ARM: OMAP4: clock data: get rid of unused USB host clock aliases
On Mon, 10 Dec 2012, Roger Quadros wrote: > We don't need multiple aliases for the OMAP USB host clocks so remove them. > > CC: Paul Walmsley > CC: Rajendra Nayak > CC: Benoit Cousson > CC: Mike Turquette > > Signed-off-by: Roger Quadros Acked-by: Paul Walmsley - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 21/23] ARM: OMAP3: clock data: get rid of unused USB host clock aliases and dummies
On Mon, 10 Dec 2012, Roger Quadros wrote: > We don't need multiple aliases for the OMAP USB host clocks and neither > the dummy clocks so remove them. > > CC: Paul Walmsley > CC: Rajendra Nayak > CC: Benoit Cousson > CC: Mike Turquette > > Signed-off-by: Roger Quadros Acked-by: Paul Walmsley - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM335x BeagleBone SPI Issues
On 10/12/12 15:26, Shubhrajyoti Datta wrote:
On Mon, Dec 10, 2012 at 8:49 PM, Jack Mitchell wrote:
On 10/12/12 14:59, Felipe Balbi wrote:
Hi,
On Mon, Dec 10, 2012 at 02:50:16PM +, Jack Mitchell wrote:
On Mon, Dec 10, 2012 at 01:23:09PM +, Jack Mitchell wrote:
Hi,
I am currently having issues with the SPI driver on the beaglebone
using the 3.7-rc8 kernel[1]. I have probed the SPI pins and I have
found that writing works however reading doesn't. When using DMA the
program seems to lock hard and no data is sent on the bus. I am
testing the bus using spidev and the spidev_test[2] application,
however I first came across spi issues with a custom spi driver which
stopped working when I transitioned from 3.2-psp to 3.7-rc8.
The current output I am seeing from the spidev_test program is just a
series of 0x00 data, which looks to me like no data is getting in at
all. The spidev_test program is not using DMA as the buffer size is
too low, so I forced the dma on when buffer size is > 1 and the
program hangs hard with the system still responding to other
commands.I have briged the pins 18 and 21 on the BeagleBone P9
header.
Has anyone seen issues like this, or if not if someone could please
test the latest 3.7-rc8 from [1] and let me know if it works for them
and the issue is at my end.
To get spidev working with devicetree I applied the patch from [3]
and changed the dtb as in the patch pasted below.
[1] https://github.com/beagleboard/kernel/tree/3.7
[2] http://lxr.linux.no/#linux+v3.6.9/Documentation/spi/spidev_test.c
[3]
http://www.mail-archive.com/spi-devel-general@lists.sourceforge.net/msg09958.html
do you have any debugging output from that driver ? It would be cool to
see if DMA is at least being kicked properly for small transfers.
When I run the spidev program with dma for transfers > 1, the program
hangs and the only output in dmesg is:
[ 12.613952] libphy: 4a101000.mdio:00 - Link is Up - 100/Full <
Last line from initial log in [2]
[ 47.669202] spidev spi1.0: setup: speed 2400, sample leading
edge, clk normal
[ 47.669246] spidev spi1.0: setup mode 0, 8 bits/w, 2400 Hz max -->
0
[ 47.669260] spidev spi1.0: spi mode 00
[ 47.669283] spidev spi1.0: setup: speed 2400, sample leading
edge, clk normal
[ 47.669300] spidev spi1.0: setup mode 0, 16 bits/w, 2400 Hz max
--> 0
[ 47.669312] spidev spi1.0: 16 bits per word
[ 47.669330] spidev spi1.0: setup: speed 2400, sample leading
edge, clk normal
[ 47.669347] spidev spi1.0: setup mode 0, 16 bits/w, 2400 Hz max
--> 0
[ 47.669358] spidev spi1.0: 2400 Hz (max)
[ 47.673811] spidev spi1.0: setup: speed 2400, sample leading
edge, clk normal
The initial dmesg statup log is at [2].
can you apply the debugging patch below to spi driver and show me the
output again ?
Note that I'm allowing DMA for as small as 1-byte transfers (as you
needed) and I'm also disabling DMA Request line before calling
complete() as I think the current way could race, but likely wouldn't
cause issues. Anyway, please show me the output.
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 3542fdc..d2b1af2 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -108,7 +108,7 @@ struct omap2_mcspi_dma {
/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
* cache operations; better heuristics consider wordsize and bitrate.
*/
-#define DMA_MIN_BYTES 160
+#define DMA_MIN_BYTES 1
/*
@@ -298,10 +298,11 @@ static void omap2_mcspi_rx_callback(void *data)
struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master);
struct omap2_mcspi_dma *mcspi_dma =
&mcspi->dma_channels[spi->chip_select];
- complete(&mcspi_dma->dma_rx_completion);
-
/* We must disable the DMA RX request */
+ dev_info(&spi->dev, "Disabling RX Request Line\n");
omap2_mcspi_set_dma_req(spi, 1, 0);
+
+ complete(&mcspi_dma->dma_rx_completion);
}
static void omap2_mcspi_tx_callback(void *data)
@@ -310,10 +311,11 @@ static void omap2_mcspi_tx_callback(void *data)
struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master);
struct omap2_mcspi_dma *mcspi_dma =
&mcspi->dma_channels[spi->chip_select];
- complete(&mcspi_dma->dma_tx_completion);
-
/* We must disable the DMA TX request */
+ dev_info(&spi->dev, "Disabling TX Request Line\n");
omap2_mcspi_set_dma_req(spi, 0, 0);
+
+ complete(&mcspi_dma->dma_tx_completion);
}
static void omap2_mcspi_tx_dma(struct spi_device *spi,
@@ -328,6 +330,7 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi,
void __iomem*chstat_reg;
struct omap2_mcspi_cs *cs = spi->controller_state;
+ dev_info(&spi->dev, "kicking TX DMA\n");
mcspi = spi_master_get_devdata(spi->master);
mcspi_dma = &mcspi->dma_channels[spi->chip_select];
Re: AM335x BeagleBone SPI Issues
On Mon, Dec 10, 2012 at 8:49 PM, Jack Mitchell wrote:
> On 10/12/12 14:59, Felipe Balbi wrote:
>>
>> Hi,
>>
>> On Mon, Dec 10, 2012 at 02:50:16PM +, Jack Mitchell wrote:
On Mon, Dec 10, 2012 at 01:23:09PM +, Jack Mitchell wrote:
>
> Hi,
>
> I am currently having issues with the SPI driver on the beaglebone
> using the 3.7-rc8 kernel[1]. I have probed the SPI pins and I have
> found that writing works however reading doesn't. When using DMA the
> program seems to lock hard and no data is sent on the bus. I am
> testing the bus using spidev and the spidev_test[2] application,
> however I first came across spi issues with a custom spi driver which
> stopped working when I transitioned from 3.2-psp to 3.7-rc8.
>
> The current output I am seeing from the spidev_test program is just a
> series of 0x00 data, which looks to me like no data is getting in at
> all. The spidev_test program is not using DMA as the buffer size is
> too low, so I forced the dma on when buffer size is > 1 and the
> program hangs hard with the system still responding to other
> commands.I have briged the pins 18 and 21 on the BeagleBone P9
> header.
>
> Has anyone seen issues like this, or if not if someone could please
> test the latest 3.7-rc8 from [1] and let me know if it works for them
> and the issue is at my end.
>
> To get spidev working with devicetree I applied the patch from [3]
> and changed the dtb as in the patch pasted below.
>
> [1] https://github.com/beagleboard/kernel/tree/3.7
> [2] http://lxr.linux.no/#linux+v3.6.9/Documentation/spi/spidev_test.c
> [3]
> http://www.mail-archive.com/spi-devel-general@lists.sourceforge.net/msg09958.html
do you have any debugging output from that driver ? It would be cool to
see if DMA is at least being kicked properly for small transfers.
>>>
>>> When I run the spidev program with dma for transfers > 1, the program
>>> hangs and the only output in dmesg is:
>>>
>>> [ 12.613952] libphy: 4a101000.mdio:00 - Link is Up - 100/Full <
>>> Last line from initial log in [2]
>>> [ 47.669202] spidev spi1.0: setup: speed 2400, sample leading
>>> edge, clk normal
>>> [ 47.669246] spidev spi1.0: setup mode 0, 8 bits/w, 2400 Hz max -->
>>> 0
>>> [ 47.669260] spidev spi1.0: spi mode 00
>>> [ 47.669283] spidev spi1.0: setup: speed 2400, sample leading
>>> edge, clk normal
>>> [ 47.669300] spidev spi1.0: setup mode 0, 16 bits/w, 2400 Hz max
>>> --> 0
>>> [ 47.669312] spidev spi1.0: 16 bits per word
>>> [ 47.669330] spidev spi1.0: setup: speed 2400, sample leading
>>> edge, clk normal
>>> [ 47.669347] spidev spi1.0: setup mode 0, 16 bits/w, 2400 Hz max
>>> --> 0
>>> [ 47.669358] spidev spi1.0: 2400 Hz (max)
>>> [ 47.673811] spidev spi1.0: setup: speed 2400, sample leading
>>> edge, clk normal
>>>
>>> The initial dmesg statup log is at [2].
>>
>> can you apply the debugging patch below to spi driver and show me the
>> output again ?
>>
>> Note that I'm allowing DMA for as small as 1-byte transfers (as you
>> needed) and I'm also disabling DMA Request line before calling
>> complete() as I think the current way could race, but likely wouldn't
>> cause issues. Anyway, please show me the output.
>>
>> diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
>> index 3542fdc..d2b1af2 100644
>> --- a/drivers/spi/spi-omap2-mcspi.c
>> +++ b/drivers/spi/spi-omap2-mcspi.c
>> @@ -108,7 +108,7 @@ struct omap2_mcspi_dma {
>> /* use PIO for small transfers, avoiding DMA setup/teardown overhead and
>>* cache operations; better heuristics consider wordsize and bitrate.
>>*/
>> -#define DMA_MIN_BYTES 160
>> +#define DMA_MIN_BYTES 1
>> /*
>> @@ -298,10 +298,11 @@ static void omap2_mcspi_rx_callback(void *data)
>> struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master);
>> struct omap2_mcspi_dma *mcspi_dma =
>> &mcspi->dma_channels[spi->chip_select];
>> - complete(&mcspi_dma->dma_rx_completion);
>> -
>> /* We must disable the DMA RX request */
>> + dev_info(&spi->dev, "Disabling RX Request Line\n");
>> omap2_mcspi_set_dma_req(spi, 1, 0);
>> +
>> + complete(&mcspi_dma->dma_rx_completion);
>> }
>> static void omap2_mcspi_tx_callback(void *data)
>> @@ -310,10 +311,11 @@ static void omap2_mcspi_tx_callback(void *data)
>> struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master);
>> struct omap2_mcspi_dma *mcspi_dma =
>> &mcspi->dma_channels[spi->chip_select];
>> - complete(&mcspi_dma->dma_tx_completion);
>> -
>> /* We must disable the DMA TX request */
>> + dev_info(&spi->dev, "Disabling TX Request Line\n");
>> omap2_mcspi_set_dma_req(spi, 0, 0);
>> +
>> + complete(&mcspi_dma->dma_tx_completion);
>> }
>> static void omap2_mcspi_tx_
Re: AM335x BeagleBone SPI Issues
On 10/12/12 14:59, Felipe Balbi wrote:
Hi,
On Mon, Dec 10, 2012 at 02:50:16PM +, Jack Mitchell wrote:
On Mon, Dec 10, 2012 at 01:23:09PM +, Jack Mitchell wrote:
Hi,
I am currently having issues with the SPI driver on the beaglebone
using the 3.7-rc8 kernel[1]. I have probed the SPI pins and I have
found that writing works however reading doesn't. When using DMA the
program seems to lock hard and no data is sent on the bus. I am
testing the bus using spidev and the spidev_test[2] application,
however I first came across spi issues with a custom spi driver which
stopped working when I transitioned from 3.2-psp to 3.7-rc8.
The current output I am seeing from the spidev_test program is just a
series of 0x00 data, which looks to me like no data is getting in at
all. The spidev_test program is not using DMA as the buffer size is
too low, so I forced the dma on when buffer size is > 1 and the
program hangs hard with the system still responding to other
commands.I have briged the pins 18 and 21 on the BeagleBone P9
header.
Has anyone seen issues like this, or if not if someone could please
test the latest 3.7-rc8 from [1] and let me know if it works for them
and the issue is at my end.
To get spidev working with devicetree I applied the patch from [3]
and changed the dtb as in the patch pasted below.
[1] https://github.com/beagleboard/kernel/tree/3.7
[2] http://lxr.linux.no/#linux+v3.6.9/Documentation/spi/spidev_test.c
[3]
http://www.mail-archive.com/spi-devel-general@lists.sourceforge.net/msg09958.html
do you have any debugging output from that driver ? It would be cool to
see if DMA is at least being kicked properly for small transfers.
When I run the spidev program with dma for transfers > 1, the program
hangs and the only output in dmesg is:
[ 12.613952] libphy: 4a101000.mdio:00 - Link is Up - 100/Full <
Last line from initial log in [2]
[ 47.669202] spidev spi1.0: setup: speed 2400, sample leading
edge, clk normal
[ 47.669246] spidev spi1.0: setup mode 0, 8 bits/w, 2400 Hz max --> 0
[ 47.669260] spidev spi1.0: spi mode 00
[ 47.669283] spidev spi1.0: setup: speed 2400, sample leading
edge, clk normal
[ 47.669300] spidev spi1.0: setup mode 0, 16 bits/w, 2400 Hz max --> 0
[ 47.669312] spidev spi1.0: 16 bits per word
[ 47.669330] spidev spi1.0: setup: speed 2400, sample leading
edge, clk normal
[ 47.669347] spidev spi1.0: setup mode 0, 16 bits/w, 2400 Hz max --> 0
[ 47.669358] spidev spi1.0: 2400 Hz (max)
[ 47.673811] spidev spi1.0: setup: speed 2400, sample leading
edge, clk normal
The initial dmesg statup log is at [2].
can you apply the debugging patch below to spi driver and show me the
output again ?
Note that I'm allowing DMA for as small as 1-byte transfers (as you
needed) and I'm also disabling DMA Request line before calling
complete() as I think the current way could race, but likely wouldn't
cause issues. Anyway, please show me the output.
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 3542fdc..d2b1af2 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -108,7 +108,7 @@ struct omap2_mcspi_dma {
/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
* cache operations; better heuristics consider wordsize and bitrate.
*/
-#define DMA_MIN_BYTES 160
+#define DMA_MIN_BYTES 1
/*
@@ -298,10 +298,11 @@ static void omap2_mcspi_rx_callback(void *data)
struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master);
struct omap2_mcspi_dma *mcspi_dma =
&mcspi->dma_channels[spi->chip_select];
- complete(&mcspi_dma->dma_rx_completion);
-
/* We must disable the DMA RX request */
+ dev_info(&spi->dev, "Disabling RX Request Line\n");
omap2_mcspi_set_dma_req(spi, 1, 0);
+
+ complete(&mcspi_dma->dma_rx_completion);
}
static void omap2_mcspi_tx_callback(void *data)
@@ -310,10 +311,11 @@ static void omap2_mcspi_tx_callback(void *data)
struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master);
struct omap2_mcspi_dma *mcspi_dma =
&mcspi->dma_channels[spi->chip_select];
- complete(&mcspi_dma->dma_tx_completion);
-
/* We must disable the DMA TX request */
+ dev_info(&spi->dev, "Disabling TX Request Line\n");
omap2_mcspi_set_dma_req(spi, 0, 0);
+
+ complete(&mcspi_dma->dma_tx_completion);
}
static void omap2_mcspi_tx_dma(struct spi_device *spi,
@@ -328,6 +330,7 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi,
void __iomem*chstat_reg;
struct omap2_mcspi_cs *cs = spi->controller_state;
+ dev_info(&spi->dev, "kicking TX DMA\n");
mcspi = spi_master_get_devdata(spi->master);
mcspi_dma = &mcspi->dma_channels[spi->chip_select];
count = xfer->len;
@@ -359,7 +362,9 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi,
dma_async_
Re: AM335x BeagleBone SPI Issues
Hi,
On Mon, Dec 10, 2012 at 02:50:16PM +, Jack Mitchell wrote:
> >On Mon, Dec 10, 2012 at 01:23:09PM +, Jack Mitchell wrote:
> >>Hi,
> >>
> >>I am currently having issues with the SPI driver on the beaglebone
> >>using the 3.7-rc8 kernel[1]. I have probed the SPI pins and I have
> >>found that writing works however reading doesn't. When using DMA the
> >>program seems to lock hard and no data is sent on the bus. I am
> >>testing the bus using spidev and the spidev_test[2] application,
> >>however I first came across spi issues with a custom spi driver which
> >>stopped working when I transitioned from 3.2-psp to 3.7-rc8.
> >>
> >>The current output I am seeing from the spidev_test program is just a
> >>series of 0x00 data, which looks to me like no data is getting in at
> >>all. The spidev_test program is not using DMA as the buffer size is
> >>too low, so I forced the dma on when buffer size is > 1 and the
> >>program hangs hard with the system still responding to other
> >>commands.I have briged the pins 18 and 21 on the BeagleBone P9
> >>header.
> >>
> >>Has anyone seen issues like this, or if not if someone could please
> >>test the latest 3.7-rc8 from [1] and let me know if it works for them
> >>and the issue is at my end.
> >>
> >>To get spidev working with devicetree I applied the patch from [3]
> >>and changed the dtb as in the patch pasted below.
> >>
> >>[1] https://github.com/beagleboard/kernel/tree/3.7
> >>[2] http://lxr.linux.no/#linux+v3.6.9/Documentation/spi/spidev_test.c
> >>[3]
> >>http://www.mail-archive.com/spi-devel-general@lists.sourceforge.net/msg09958.html
> >do you have any debugging output from that driver ? It would be cool to
> >see if DMA is at least being kicked properly for small transfers.
>
> When I run the spidev program with dma for transfers > 1, the program
> hangs and the only output in dmesg is:
>
> [ 12.613952] libphy: 4a101000.mdio:00 - Link is Up - 100/Full <
> Last line from initial log in [2]
> [ 47.669202] spidev spi1.0: setup: speed 2400, sample leading
> edge, clk normal
> [ 47.669246] spidev spi1.0: setup mode 0, 8 bits/w, 2400 Hz max --> 0
> [ 47.669260] spidev spi1.0: spi mode 00
> [ 47.669283] spidev spi1.0: setup: speed 2400, sample leading
> edge, clk normal
> [ 47.669300] spidev spi1.0: setup mode 0, 16 bits/w, 2400 Hz max --> 0
> [ 47.669312] spidev spi1.0: 16 bits per word
> [ 47.669330] spidev spi1.0: setup: speed 2400, sample leading
> edge, clk normal
> [ 47.669347] spidev spi1.0: setup mode 0, 16 bits/w, 2400 Hz max --> 0
> [ 47.669358] spidev spi1.0: 2400 Hz (max)
> [ 47.673811] spidev spi1.0: setup: speed 2400, sample leading
> edge, clk normal
>
> The initial dmesg statup log is at [2].
can you apply the debugging patch below to spi driver and show me the
output again ?
Note that I'm allowing DMA for as small as 1-byte transfers (as you
needed) and I'm also disabling DMA Request line before calling
complete() as I think the current way could race, but likely wouldn't
cause issues. Anyway, please show me the output.
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 3542fdc..d2b1af2 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -108,7 +108,7 @@ struct omap2_mcspi_dma {
/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
* cache operations; better heuristics consider wordsize and bitrate.
*/
-#define DMA_MIN_BYTES 160
+#define DMA_MIN_BYTES 1
/*
@@ -298,10 +298,11 @@ static void omap2_mcspi_rx_callback(void *data)
struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master);
struct omap2_mcspi_dma *mcspi_dma =
&mcspi->dma_channels[spi->chip_select];
- complete(&mcspi_dma->dma_rx_completion);
-
/* We must disable the DMA RX request */
+ dev_info(&spi->dev, "Disabling RX Request Line\n");
omap2_mcspi_set_dma_req(spi, 1, 0);
+
+ complete(&mcspi_dma->dma_rx_completion);
}
static void omap2_mcspi_tx_callback(void *data)
@@ -310,10 +311,11 @@ static void omap2_mcspi_tx_callback(void *data)
struct omap2_mcspi *mcspi = spi_master_get_devdata(spi->master);
struct omap2_mcspi_dma *mcspi_dma =
&mcspi->dma_channels[spi->chip_select];
- complete(&mcspi_dma->dma_tx_completion);
-
/* We must disable the DMA TX request */
+ dev_info(&spi->dev, "Disabling TX Request Line\n");
omap2_mcspi_set_dma_req(spi, 0, 0);
+
+ complete(&mcspi_dma->dma_tx_completion);
}
static void omap2_mcspi_tx_dma(struct spi_device *spi,
@@ -328,6 +330,7 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi,
void __iomem*chstat_reg;
struct omap2_mcspi_cs *cs = spi->controller_state;
+ dev_info(&spi->dev, "kicking TX DMA\n");
mcspi = spi_master_get_devdata(spi->master);
mcspi_dma = &mcspi->dma_channels[spi->chip_select]
Re: AM335x BeagleBone SPI Issues
Hi Felipe, On 10/12/12 13:53, Felipe Balbi wrote: Hi, On Mon, Dec 10, 2012 at 01:23:09PM +, Jack Mitchell wrote: Hi, I am currently having issues with the SPI driver on the beaglebone using the 3.7-rc8 kernel[1]. I have probed the SPI pins and I have found that writing works however reading doesn't. When using DMA the program seems to lock hard and no data is sent on the bus. I am testing the bus using spidev and the spidev_test[2] application, however I first came across spi issues with a custom spi driver which stopped working when I transitioned from 3.2-psp to 3.7-rc8. The current output I am seeing from the spidev_test program is just a series of 0x00 data, which looks to me like no data is getting in at all. The spidev_test program is not using DMA as the buffer size is too low, so I forced the dma on when buffer size is > 1 and the program hangs hard with the system still responding to other commands.I have briged the pins 18 and 21 on the BeagleBone P9 header. Has anyone seen issues like this, or if not if someone could please test the latest 3.7-rc8 from [1] and let me know if it works for them and the issue is at my end. To get spidev working with devicetree I applied the patch from [3] and changed the dtb as in the patch pasted below. [1] https://github.com/beagleboard/kernel/tree/3.7 [2] http://lxr.linux.no/#linux+v3.6.9/Documentation/spi/spidev_test.c [3] http://www.mail-archive.com/spi-devel-general@lists.sourceforge.net/msg09958.html do you have any debugging output from that driver ? It would be cool to see if DMA is at least being kicked properly for small transfers. When I run the spidev program with dma for transfers > 1, the program hangs and the only output in dmesg is: [ 12.613952] libphy: 4a101000.mdio:00 - Link is Up - 100/Full < Last line from initial log in [2] [ 47.669202] spidev spi1.0: setup: speed 2400, sample leading edge, clk normal [ 47.669246] spidev spi1.0: setup mode 0, 8 bits/w, 2400 Hz max --> 0 [ 47.669260] spidev spi1.0: spi mode 00 [ 47.669283] spidev spi1.0: setup: speed 2400, sample leading edge, clk normal [ 47.669300] spidev spi1.0: setup mode 0, 16 bits/w, 2400 Hz max --> 0 [ 47.669312] spidev spi1.0: 16 bits per word [ 47.669330] spidev spi1.0: setup: speed 2400, sample leading edge, clk normal [ 47.669347] spidev spi1.0: setup mode 0, 16 bits/w, 2400 Hz max --> 0 [ 47.669358] spidev spi1.0: 2400 Hz (max) [ 47.673811] spidev spi1.0: setup: speed 2400, sample leading edge, clk normal The initial dmesg statup log is at [2]. It would also be nice to have a clear picture of what "custom spi driver" you're talking about. The custom SPI driver is for connecting and reading registers from an in house FPGA design and can be found at [1]. It's fairly rudimentary and also in the development stages, I'm very new to Linux kernel programming so please take that into account :) However it did work flawlessly with 3.2-psp. cheers [1] http://embed.me.uk/fpgaSPI.c [2] http://embed.me.uk/bone-log.1 Cheers, -- Jack Mitchell (j...@embed.me.uk) Embedded Systems Engineer http://www.embed.me.uk -- -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 23/23] mfd: omap-usb-host: Don't spam console on clk_set_parent failure
On Mon, Dec 10, 2012 at 01:31:22PM +0200, Roger Quadros wrote: > On 12/10/2012 01:24 PM, Rajendra Nayak wrote: > > On Monday 10 December 2012 03:50 PM, Roger Quadros wrote: > >> clk_set_parent is expected to fail on OMAP3 platforms. We don't > >> consider that as fatal so don't spam console. > > > > And what if it fails on a non-OMAP3 platform? > > The driver just prints a debug message and continues to work just as > before. The USB port will not work for the user in that case. He will > have to enable DEBUG flag to see the debug message. I see this behaviour > better than before where all OMAP3 users see the error message for no > reason. I agree with Roger here. -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH 1/5] drivers : introduce device_path api
Hi, On Mon, Dec 10, 2012 at 11:48:51AM +0200, Roger Quadros wrote: > >>> (or in appropriate order if the above isn't) > >>> That way insmod/rmmod'ing the USB3320C driver would power-up/down the > >>> whole subsystem. > >> > >> Yes, this is where we can think of a generic PHY driver to make sure thy > >> PHY has necessary resources enabled. In the Panda case it would be the > >> PHY clock and RESET gpio. > >> > > I wonder if ehci-omap should assume, besides regulator, a clock might > > also be need to setup for the transceiver chip. > > Maybe "usbhs_bdata" in board-omap4panda.c should have > > .reset_gpio_port[0] = GPIO_HUB_NRESET ? > > > > Just like the regulator, reset_gpio_port has nothing to do with OMAP > EHCI. So we would want to get rid of that too from the OMAP USB driver. +1 to that. That's a requirement from the LAN95xx hub controller, not OMAP EHCI ;-) -- balbi signature.asc Description: Digital signature
Re: AM335x BeagleBone SPI Issues
Hi, On Mon, Dec 10, 2012 at 01:23:09PM +, Jack Mitchell wrote: > Hi, > > I am currently having issues with the SPI driver on the beaglebone > using the 3.7-rc8 kernel[1]. I have probed the SPI pins and I have > found that writing works however reading doesn't. When using DMA the > program seems to lock hard and no data is sent on the bus. I am > testing the bus using spidev and the spidev_test[2] application, > however I first came across spi issues with a custom spi driver which > stopped working when I transitioned from 3.2-psp to 3.7-rc8. > > The current output I am seeing from the spidev_test program is just a > series of 0x00 data, which looks to me like no data is getting in at > all. The spidev_test program is not using DMA as the buffer size is > too low, so I forced the dma on when buffer size is > 1 and the > program hangs hard with the system still responding to other > commands.I have briged the pins 18 and 21 on the BeagleBone P9 > header. > > Has anyone seen issues like this, or if not if someone could please > test the latest 3.7-rc8 from [1] and let me know if it works for them > and the issue is at my end. > > To get spidev working with devicetree I applied the patch from [3] > and changed the dtb as in the patch pasted below. > > [1] https://github.com/beagleboard/kernel/tree/3.7 > [2] http://lxr.linux.no/#linux+v3.6.9/Documentation/spi/spidev_test.c > [3] > http://www.mail-archive.com/spi-devel-general@lists.sourceforge.net/msg09958.html do you have any debugging output from that driver ? It would be cool to see if DMA is at least being kicked properly for small transfers. It would also be nice to have a clear picture of what "custom spi driver" you're talking about. cheers -- balbi signature.asc Description: Digital signature
AM335x BeagleBone SPI Issues
Hi,
I am currently having issues with the SPI driver on the beaglebone using
the 3.7-rc8 kernel[1]. I have probed the SPI pins and I have found that
writing works however reading doesn't. When using DMA the program seems
to lock hard and no data is sent on the bus. I am testing the bus using
spidev and the spidev_test[2] application, however I first came across
spi issues with a custom spi driver which stopped working when I
transitioned from 3.2-psp to 3.7-rc8.
The current output I am seeing from the spidev_test program is just a
series of 0x00 data, which looks to me like no data is getting in at
all. The spidev_test program is not using DMA as the buffer size is too
low, so I forced the dma on when buffer size is > 1 and the program
hangs hard with the system still responding to other commands.I have
briged the pins 18 and 21 on the BeagleBone P9 header.
Has anyone seen issues like this, or if not if someone could please test
the latest 3.7-rc8 from [1] and let me know if it works for them and the
issue is at my end.
To get spidev working with devicetree I applied the patch from [3] and
changed the dtb as in the patch pasted below.
[1] https://github.com/beagleboard/kernel/tree/3.7
[2] http://lxr.linux.no/#linux+v3.6.9/Documentation/spi/spidev_test.c
[3]
http://www.mail-archive.com/spi-devel-general@lists.sourceforge.net/msg09958.html
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 543365d..8fff665 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -440,10 +440,19 @@
};
&spi0 {
+ status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&spi0_pins>;
+
+ spidev: spidev@0 {
+ compatible = "linux,spidev";
+ reg = <0>;
+ spi-max-frequency = <2400>;
+ };
+
};
+
&spi1 {
pinctrl-names = "default";
pinctrl-0 = <&spi1_pins>;
--
Jack Mitchell (j...@embed.me.uk)
Embedded Systems Engineer
http://www.embed.me.uk
--
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
AM335x BeagleBone SPI Issues
Hi,
I am currently having issues with the SPI driver on the beaglebone using
the 3.7-rc8 kernel[1]. I have probed the SPI pins and I have found that
writing works however reading doesn't. When using DMA the program seems
to lock hard and no data is sent on the bus. I am testing the bus using
spidev and the spidev_test[2] application, however I first came across
spi issues with a custom spi driver which stopped working when I
transitioned from 3.2-psp to 3.7-rc8.
The current output I am seeing from the spidev_test program is just a
series of 0x00 data, which looks to me like no data is getting in at
all. The spidev_test program is not using DMA as the buffer size is too
low, so I forced the dma on when buffer size is > 1 and the program
hangs hard with the system still responding to other commands.I have
briged the pins 18 and 21 on the BeagleBone P9 header.
Has anyone seen issues like this, or if not if someone could please test
the latest 3.7-rc8 from [1] and let me know if it works for them and the
issue is at my end.
To get spidev working with devicetree I applied the patch from [3] and
changed the dtb as in the patch pasted below.
[1] https://github.com/beagleboard/kernel/tree/3.7
[2] http://lxr.linux.no/#linux+v3.6.9/Documentation/spi/spidev_test.c
[3]
http://www.mail-archive.com/spi-devel-general@lists.sourceforge.net/msg09958.html
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 543365d..8fff665 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -440,10 +440,19 @@
};
&spi0 {
+ status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&spi0_pins>;
+
+ spidev: spidev@0 {
+ compatible = "linux,spidev";
+ reg = <0>;
+ spi-max-frequency = <2400>;
+ };
+
};
+
&spi1 {
pinctrl-names = "default";
pinctrl-0 = <&spi1_pins>;
--
Jack Mitchell (j...@embed.me.uk)
Embedded Systems Engineer
http://www.embed.me.uk
--
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 23/23] mfd: omap-usb-host: Don't spam console on clk_set_parent failure
On 12/10/2012 01:24 PM, Rajendra Nayak wrote:
> On Monday 10 December 2012 03:50 PM, Roger Quadros wrote:
>> clk_set_parent is expected to fail on OMAP3 platforms. We don't
>> consider that as fatal so don't spam console.
>
> And what if it fails on a non-OMAP3 platform?
The driver just prints a debug message and continues to work just as
before. The USB port will not work for the user in that case. He will
have to enable DEBUG flag to see the debug message. I see this behaviour
better than before where all OMAP3 users see the error message for no
reason.
cheers,
-roger
>
>>
>> Signed-off-by: Roger Quadros
>> ---
>> drivers/mfd/omap-usb-host.c | 18 +-
>> 1 files changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>> index 0bb54393..344ce09 100644
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap-usb-host.c
>> @@ -657,32 +657,32 @@ static int __devinit usbhs_omap_probe(struct
>> platform_device *pdev)
>> }
>>
>> if (is_ehci_phy_mode(pdata->port_mode[0])) {
>> -/* for OMAP3 , the clk set paretn fails */
>> +/* for OMAP3, clk_set_parent fails */
>> ret = clk_set_parent(omap->utmi_clk[0],
>> omap->xclk60mhsp1_ck);
>> if (ret != 0)
>> -dev_err(dev, "xclk60mhsp1_ck set parent"
>> -"failed error:%d\n", ret);
>> +dev_dbg(dev, "xclk60mhsp1_ck set parent failed: %d\n",
>> +ret);
>> } else if (is_ehci_tll_mode(pdata->port_mode[0])) {
>> ret = clk_set_parent(omap->utmi_clk[0],
>> omap->init_60m_fclk);
>> if (ret != 0)
>> -dev_err(dev, "init_60m_fclk set parent"
>> -"failed error:%d\n", ret);
>> +dev_dbg(dev, "P0 init_60m_fclk set parent failed: %d\n",
>> +ret);
>> }
>>
>> if (is_ehci_phy_mode(pdata->port_mode[1])) {
>> ret = clk_set_parent(omap->utmi_clk[1],
>> omap->xclk60mhsp2_ck);
>> if (ret != 0)
>> -dev_err(dev, "xclk60mhsp2_ck set parent"
>> -"failed error:%d\n", ret);
>> +dev_dbg(dev, "xclk60mhsp2_ck set parent failed: %d\n",
>> +ret);
>> } else if (is_ehci_tll_mode(pdata->port_mode[1])) {
>> ret = clk_set_parent(omap->utmi_clk[1],
>> omap->init_60m_fclk);
>> if (ret != 0)
>> -dev_err(dev, "init_60m_fclk set parent"
>> -"failed error:%d\n", ret);
>> +dev_dbg(dev, "P1 init_60m_fclk set parent failed: %d\n",
>> +ret);
>> }
>>
>> omap_usbhs_init(dev);
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] net: ethernet: davinci_cpdma: Add boundary for rx and tx descriptors
On 12/10/2012 1:54 PM, Christian Riesch wrote: Hi again, On Mon, Dec 10, 2012 at 8:37 AM, Mugunthan V N wrote: When there is heavy transmission traffic in the CPDMA, then Rx descriptors memory is also utilized as tx desc memory this leads to reduced rx desc memory which leads to poor performance. "poor performance" is an understatement, see Sascha's description of his patch. At initialization of the driver, half of the descriptors in the pool are allocated for rx. When a packet arrives, one of the rx descriptors is released and a new one is allocated. If tx allocates this descriptor in the meantime, it is lost for rx forever! If tx consumes all rx descriptors this way, the rx channel is dead! Regards, Christian This patch adds boundary for tx and rx descriptors in bd ram dividing the descriptor memory to ensure that during heavy transmission tx doesn't use rx descriptors. This patch is already applied to davinci_emac driver, since CPSW and davici_dmac uses the same CPDMA, moving the boundry seperation from Davinci EMAC driver to CPDMA driver which was done in the following commit commit 86d8c07ff2448eb4e860e50f34ef6ee78e45c40c Author: Sascha Hauer Date: Tue Jan 3 05:27:47 2012 + net/davinci: do not use all descriptors for tx packets The driver uses a shared pool for both rx and tx descriptors. During open it queues fixed number of 128 descriptors for receive packets. For each received packet it tries to queue another descriptor. If this fails the descriptor is lost for rx. The driver has no limitation on tx descriptors to use, so it can happen during a nmap / ping -f attack that the driver allocates all descriptors for tx and looses all rx descriptors. The driver stops working then. To fix this limit the number of tx descriptors used to half of the descriptors available, the rx path uses the other half. Tested on a custom board using nmap / ping -f to the board from two different hosts. Signed-off-by: Mugunthan V N Will change the commit description and resubmit the patch. Regards Mugunthan V N -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] net: ethernet: davinci_cpdma: Add boundary for rx and tx descriptors
On 12/10/2012 1:41 PM, Christian Riesch wrote:
Hi,
On Mon, Dec 10, 2012 at 8:37 AM, Mugunthan V N wrote:
When there is heavy transmission traffic in the CPDMA, then Rx descriptors
memory is also utilized as tx desc memory this leads to reduced rx desc memory
which leads to poor performance.
This patch adds boundary for tx and rx descriptors in bd ram dividing the
descriptor memory to ensure that during heavy transmission tx doesn't use
rx descriptors.
This patch is already applied to davinci_emac driver, since CPSW and
davici_dmac uses the same CPDMA, moving the boundry seperation from
Davinci EMAC driver to CPDMA driver which was done in the following
commit
commit 86d8c07ff2448eb4e860e50f34ef6ee78e45c40c
Author: Sascha Hauer
Date: Tue Jan 3 05:27:47 2012 +
net/davinci: do not use all descriptors for tx packets
The driver uses a shared pool for both rx and tx descriptors.
During open it queues fixed number of 128 descriptors for receive
packets. For each received packet it tries to queue another
descriptor. If this fails the descriptor is lost for rx.
The driver has no limitation on tx descriptors to use, so it
can happen during a nmap / ping -f attack that the driver
allocates all descriptors for tx and looses all rx descriptors.
The driver stops working then.
To fix this limit the number of tx descriptors used to half of
the descriptors available, the rx path uses the other half.
Tested on a custom board using nmap / ping -f to the board from
two different hosts.
Signed-off-by: Mugunthan V N
---
drivers/net/ethernet/ti/davinci_cpdma.c | 20 ++--
drivers/net/ethernet/ti/davinci_emac.c |8
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c
b/drivers/net/ethernet/ti/davinci_cpdma.c
index 4995673..d37f546 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -105,13 +105,13 @@ struct cpdma_ctlr {
};
struct cpdma_chan {
+ struct cpdma_desc __iomem *head, *tail;
+ void __iomem*hdp, *cp, *rxfree;
enum cpdma_statestate;
struct cpdma_ctlr *ctlr;
int chan_num;
spinlock_t lock;
- struct cpdma_desc __iomem *head, *tail;
int count;
- void __iomem*hdp, *cp, *rxfree;
Why?
Its just a code clean-up to have iomem variables at one place.
u32 mask;
cpdma_handler_fnhandler;
enum dma_data_direction dir;
@@ -217,7 +217,7 @@ desc_from_phys(struct cpdma_desc_pool *pool, dma_addr_t dma)
}
static struct cpdma_desc __iomem *
-cpdma_desc_alloc(struct cpdma_desc_pool *pool, int num_desc)
+cpdma_desc_alloc(struct cpdma_desc_pool *pool, int num_desc, bool is_rx)
{
unsigned long flags;
int index;
@@ -225,8 +225,14 @@ cpdma_desc_alloc(struct cpdma_desc_pool *pool, int
num_desc)
spin_lock_irqsave(&pool->lock, flags);
- index = bitmap_find_next_zero_area(pool->bitmap, pool->num_desc, 0,
- num_desc, 0);
+ if (is_rx) {
+ index = bitmap_find_next_zero_area(pool->bitmap,
+ pool->num_desc/2, 0, num_desc, 0);
+} else {
+ index = bitmap_find_next_zero_area(pool->bitmap,
+ pool->num_desc, pool->num_desc/2, num_desc, 0);
+ }
Would it make sense to use two separate pools for rx and tx instead,
struct cpdma_desc_pool *rxpool, *txpool? It would result in using
separate spinlocks for rx and tx, could this be an advantage? (I am a
newbie in this field...)
I don't think separating pool will give an advantage, the same is
achieved by separating
the pool into first half and last half.
Regards
Mugunthan V N
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 23/23] mfd: omap-usb-host: Don't spam console on clk_set_parent failure
On Monday 10 December 2012 03:50 PM, Roger Quadros wrote:
clk_set_parent is expected to fail on OMAP3 platforms. We don't
consider that as fatal so don't spam console.
And what if it fails on a non-OMAP3 platform?
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 0bb54393..344ce09 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -657,32 +657,32 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
}
if (is_ehci_phy_mode(pdata->port_mode[0])) {
- /* for OMAP3 , the clk set paretn fails */
+ /* for OMAP3, clk_set_parent fails */
ret = clk_set_parent(omap->utmi_clk[0],
omap->xclk60mhsp1_ck);
if (ret != 0)
- dev_err(dev, "xclk60mhsp1_ck set parent"
- "failed error:%d\n", ret);
+ dev_dbg(dev, "xclk60mhsp1_ck set parent failed: %d\n",
+ ret);
} else if (is_ehci_tll_mode(pdata->port_mode[0])) {
ret = clk_set_parent(omap->utmi_clk[0],
omap->init_60m_fclk);
if (ret != 0)
- dev_err(dev, "init_60m_fclk set parent"
- "failed error:%d\n", ret);
+ dev_dbg(dev, "P0 init_60m_fclk set parent failed: %d\n",
+ ret);
}
if (is_ehci_phy_mode(pdata->port_mode[1])) {
ret = clk_set_parent(omap->utmi_clk[1],
omap->xclk60mhsp2_ck);
if (ret != 0)
- dev_err(dev, "xclk60mhsp2_ck set parent"
- "failed error:%d\n", ret);
+ dev_dbg(dev, "xclk60mhsp2_ck set parent failed: %d\n",
+ ret);
} else if (is_ehci_tll_mode(pdata->port_mode[1])) {
ret = clk_set_parent(omap->utmi_clk[1],
omap->init_60m_fclk);
if (ret != 0)
- dev_err(dev, "init_60m_fclk set parent"
- "failed error:%d\n", ret);
+ dev_dbg(dev, "P1 init_60m_fclk set parent failed: %d\n",
+ ret);
}
omap_usbhs_init(dev);
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] OMAPFB: connect ovl managers to all dssdevs
On 2012-12-10 12:53, Archit Taneja wrote: > On Monday 10 December 2012 03:37 PM, Tomi Valkeinen wrote: >> On 2012-12-10 11:54, Archit Taneja wrote: >>> On Monday 10 December 2012 01:33 PM, Tomi Valkeinen wrote: >> Another option would be to pass information about mgr-output links from the board files (or DT data) to the omapdss driver, so that omapdss could setup them at probe time. With this option omapfb/omapdrm doesn't need to care about this, and it doesn't create load order restriction. But mgr-output links are something that I'd really like to handle inside the drivers, not something that needs to be passed via platform data. >>> >>> This would definitely make things simpler, but if this parameter is put >>> in a panel's DT, it would become omap specific. We could add this info >>> to the DT corresponding to omapdss. >> >> Yes, I meant it should be omapdss platform data. Nothing related to >> panels. > > I think this is the easiest way out. We can have one parameter per > output in DT. If we do come up with a way to implement the 3rd option > below, we can always ignore those DT fields(assuming our implementation > to give the same result). So in this way, we would just be deprecating a > DT field in the future, and calculating it ourselves. I would rather go the other way around: calculate it ourselves (presuming it can be done for the current boards), and add the DT field later if we come up with boards that won't work with the dynamic approach. The reasons I'm not too happy with having the parameter in the DT data is that: - DT should be about describing the hardware connections between components, but in this case it's dynamically configurable connection. - We need to have the DT parameter for all cases, even if in 95% of cases it's not really needed. - We may never need the parameter, if we never get boards that require funny setup. > If we do use DT/platform data, would we need to parse it in omapdrm to > establish drm entities? Or do we rely on omapdss to parse the DT data > and give the links to omapdrm? I think we should parse it in omapdss and setup the connections at omapdss's probe. Then when omapfb/omapdrm starts, they can get information about the connections from omapdss, and setup their entities as they want. So omapdss would setup the mgr->output->panel links, and they would be ready for omapfb/omapdrm to use. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 5/5] OMAPFB: connect ovl managers to all dssdevs
On Monday 10 December 2012 03:37 PM, Tomi Valkeinen wrote: On 2012-12-10 11:54, Archit Taneja wrote: On Monday 10 December 2012 01:33 PM, Tomi Valkeinen wrote: Another option would be to pass information about mgr-output links from the board files (or DT data) to the omapdss driver, so that omapdss could setup them at probe time. With this option omapfb/omapdrm doesn't need to care about this, and it doesn't create load order restriction. But mgr-output links are something that I'd really like to handle inside the drivers, not something that needs to be passed via platform data. This would definitely make things simpler, but if this parameter is put in a panel's DT, it would become omap specific. We could add this info to the DT corresponding to omapdss. Yes, I meant it should be omapdss platform data. Nothing related to panels. I think this is the easiest way out. We can have one parameter per output in DT. If we do come up with a way to implement the 3rd option below, we can always ignore those DT fields(assuming our implementation to give the same result). So in this way, we would just be deprecating a DT field in the future, and calculating it ourselves. Third option, which is the best, but also something I have no idea how to implement, would be to create the mgr-output links dynamically when needed. The problem here is, of course, that a mgr could be allocated to an output, only to be later found out that that particular mgr is needed for another output. But this is something we could study a bit: can we create such mgr allocation system, that no matter what outputs the board uses, it'll just work. Yes, that would be quite useful. But I think we'll hit situations where it is sort of impossible to prevent the above situation. When an output needs a manager. We could study the current state of the system by splitting managers into 2 sets: A: managers which already have outputs connected to them B: managers which don't have an output, but might get connected to one in the future. managers in A are lost, and we can't detach them, we would need to at least disable/reenable the panel with a new manager connected to the output. we need to find one from B such that maximum outputs(or some other weightage factor) will still be supported after this new link is made. The system will initially have all managers in B, but eventually managers will move to A. We need to move one manager from B to A for every mgr-output link. I guess I just described the problem in a more mathematical way, without providing any solution :), but it does look like an optimisation problem. Well, optimization problem sounds like something that can always be solved. But in this case the driver may need to predict what outputs will be used, which is of course impossible. So, for example, on omap4, LCD2 mgr can be used for DPI, DSI2, DSI1, and RFBI. LCD1 can be used for RFBI and DSI1. If we know that DSI1 and RFBI cannot be used at the same time, we're free to give LCD1 to either one. But they can be used together, can't they? LCD1->DSI1 and LCD2->RFBI. Are you creating this constraint by assuming what the board is like? Or is this a constraint of OMAP DSS HW? I didn't check if they can be used together or not, I was just guessing. At least on OMAP3 DSI and RFBI shared the same pins, so they could not be used at the same time. Perhaps we should implement a mixed approach: the driver presumes certain things, like "if DSI is used, RFBI is not used", based on the knowledge of what kind of boards there currently are. This would allow us to manage the mgr->output connections in the driver for, say, 95% of the cases. Then we'd also have the platform data parameters for omapdss, which could be used in the weird cases. Let's just have platform data parameters :) And if we know that DPI and DSI2 cannot be used at the same time, we're also free to give LCD2 to either one. And if that's the case, there are no conflicts. This is also possible at the same time: TV->DPI and LCD2->DSI2 True. I was just again guessing. On OMAP3 DPI and DSI shared the same pins. Thinking about this, OMAP4 does have separate pins for DSI, doesn't it? So my guesses don't hold. I don't know if we can find such allocation for all current omaps, and I know it's slightly risky as the next omap could have limitations even if current ones do not. I don't understand the example so well, but I get your point of taking advantage of such limitations. Also, we would need to do this for omapdrm separately using it's own encoder/connector entities. Yep. That's also a negative side: both omapfb/omapdrm will need to implement the same stuff, even if neither of them are really interested in that stuff. Yes. I wonder if crtcs, encoders and connectors already have some sort of helpers for this? Probably nothing that helps us, as this is OMAP HW restriction. If we do use DT/platform data, would we need to parse it in omapdrm to
[PATCH v4 03/23] mfd: omap-usb-tll: Fix channel count detection
Fix channel count detecion for REV2. Also, don't give up
if we don't recognize the IP Revision. We assume the default
number of channels (i.e. 3) for unrecognized IPs.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-tll.c | 20 +++-
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 18fefdb..e67cafc 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -98,6 +98,7 @@
struct usbtll_omap {
struct clk *usbtll_p1_fck;
struct clk *usbtll_p2_fck;
+ int nch;/* num. of channels */
struct usbtll_omap_platform_data*pdata;
/* secure the register updates */
spinlock_t lock;
@@ -210,7 +211,7 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
unsignedreg;
unsigned long flags;
int ret = 0;
- int i, ver, count;
+ int i, ver;
dev_dbg(dev, "starting TI HSUSB TLL Controller\n");
@@ -262,16 +263,18 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
ver = usbtll_read(base, OMAP_USBTLL_REVISION);
switch (ver) {
case OMAP_USBTLL_REV1:
- case OMAP_USBTLL_REV2:
- count = OMAP_TLL_CHANNEL_COUNT;
+ tll->nch = OMAP_TLL_CHANNEL_COUNT;
break;
+ case OMAP_USBTLL_REV2:
case OMAP_USBTLL_REV3:
- count = OMAP_REV2_TLL_CHANNEL_COUNT;
+ tll->nch = OMAP_REV2_TLL_CHANNEL_COUNT;
break;
default:
- dev_err(dev, "TLL version failed\n");
- ret = -ENODEV;
- goto err_ioremap;
+ tll->nch = OMAP_TLL_CHANNEL_COUNT;
+ dev_dbg(dev,
+"USB TLL Rev : 0x%x not recognized, assuming %d channels\n",
+ ver, tll->nch);
+ break;
}
if (is_ehci_tll_mode(pdata->port_mode[0]) ||
@@ -291,7 +294,7 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
usbtll_write(base, OMAP_TLL_SHARED_CONF, reg);
/* Enable channels now */
- for (i = 0; i < count; i++) {
+ for (i = 0; i < tll->nch; i++) {
reg = usbtll_read(base, OMAP_TLL_CHANNEL_CONF(i));
if (is_ohci_port(pdata->port_mode[i])) {
@@ -319,7 +322,6 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
}
}
-err_ioremap:
spin_unlock_irqrestore(&tll->lock, flags);
iounmap(base);
pm_runtime_put_sync(dev);
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 06/23] mfd: omap-usb-tll: introduce and use mode_needs_tll()
This is a handy macro to check if the port requires the
USB TLL module or not. Use it to Enable the TLL module and manage
the clocks.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-tll.c | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 7d0f6cf..07370a3 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -95,6 +95,10 @@
#define is_ehci_tll_mode(x)(x == OMAP_EHCI_PORT_MODE_TLL)
+/* only PHY and UNUSED modes don't need TLL */
+#define omap_usb_mode_needs_tll(x) ((x != OMAP_USBHS_PORT_MODE_UNUSED) &&\
+(x != OMAP_EHCI_PORT_MODE_PHY))
+
struct usbtll_omap {
int nch;/* num. of channels */
struct usbtll_omap_platform_data*pdata;
@@ -211,6 +215,7 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
unsigned long flags;
int ret = 0;
int i, ver;
+ bool needs_tll;
dev_dbg(dev, "starting TI HSUSB TLL Controller\n");
@@ -278,12 +283,11 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
tll->ch_clk[i] = fck;
}
- if (is_ehci_tll_mode(pdata->port_mode[0]) ||
- is_ehci_tll_mode(pdata->port_mode[1]) ||
- is_ehci_tll_mode(pdata->port_mode[2]) ||
- is_ohci_port(pdata->port_mode[0]) ||
- is_ohci_port(pdata->port_mode[1]) ||
- is_ohci_port(pdata->port_mode[2])) {
+ needs_tll = false;
+ for (i = 0; i < tll->nch; i++)
+ needs_tll |= omap_usb_mode_needs_tll(pdata->port_mode[i]);
+
+ if (needs_tll) {
/* Program Common TLL register */
reg = usbtll_read(base, OMAP_TLL_SHARED_CONF);
@@ -371,7 +375,7 @@ static int usbtll_runtime_resume(struct device *dev)
spin_lock_irqsave(&tll->lock, flags);
for (i = 0; i < tll->nch; i++) {
- if (is_ehci_tll_mode(pdata->port_mode[i])) {
+ if (omap_usb_mode_needs_tll(pdata->port_mode[i])) {
int r;
if (!tll->ch_clk[i])
@@ -407,7 +411,7 @@ static int usbtll_runtime_suspend(struct device *dev)
spin_lock_irqsave(&tll->lock, flags);
for (i = 0; i < tll->nch; i++) {
- if (is_ehci_tll_mode(pdata->port_mode[i])) {
+ if (omap_usb_mode_needs_tll(pdata->port_mode[i])) {
if (tll->ch_clk[i])
clk_disable(tll->ch_clk[i]);
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 02/23] mfd: omap-usb-tll: Avoid creating copy of platform data
Just a pointer to the platform data should suffice.
Signed-off-by: Roger Quadros
Acked-by: Felipe Balbi
---
drivers/mfd/omap-usb-tll.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 0db0dfa..18fefdb 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -98,7 +98,7 @@
struct usbtll_omap {
struct clk *usbtll_p1_fck;
struct clk *usbtll_p2_fck;
- struct usbtll_omap_platform_dataplatdata;
+ struct usbtll_omap_platform_data*pdata;
/* secure the register updates */
spinlock_t lock;
};
@@ -223,8 +223,7 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
spin_lock_init(&tll->lock);
- for (i = 0; i < OMAP3_HS_USB_PORTS; i++)
- tll->platdata.port_mode[i] = pdata->port_mode[i];
+ tll->pdata = pdata;
tll->usbtll_p1_fck = clk_get(dev, "usb_tll_hs_usb_ch0_clk");
if (IS_ERR(tll->usbtll_p1_fck)) {
@@ -362,7 +361,7 @@ static int __devexit usbtll_omap_remove(struct
platform_device *pdev)
static int usbtll_runtime_resume(struct device *dev)
{
struct usbtll_omap *tll = dev_get_drvdata(dev);
- struct usbtll_omap_platform_data*pdata = &tll->platdata;
+ struct usbtll_omap_platform_data*pdata = tll->pdata;
unsigned long flags;
dev_dbg(dev, "usbtll_runtime_resume\n");
@@ -388,7 +387,7 @@ static int usbtll_runtime_resume(struct device *dev)
static int usbtll_runtime_suspend(struct device *dev)
{
struct usbtll_omap *tll = dev_get_drvdata(dev);
- struct usbtll_omap_platform_data*pdata = &tll->platdata;
+ struct usbtll_omap_platform_data*pdata = tll->pdata;
unsigned long flags;
dev_dbg(dev, "usbtll_runtime_suspend\n");
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 05/23] mfd: omap-usb-tll: Clean up clock handling
Every channel has a functional clock that is similarly named.
It makes sense to use a for loop to manage these clocks as OMAPs
can come with up to 3 channels.
Dynamically allocate and get channel clocks depending on the
number of clocks avaiable on the platform.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-tll.c | 93 +++-
1 files changed, 57 insertions(+), 36 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 828207f..7d0f6cf 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -96,10 +96,9 @@
#define is_ehci_tll_mode(x)(x == OMAP_EHCI_PORT_MODE_TLL)
struct usbtll_omap {
- struct clk *usbtll_p1_fck;
- struct clk *usbtll_p2_fck;
int nch;/* num. of channels */
struct usbtll_omap_platform_data*pdata;
+ struct clk **ch_clk;
/* secure the register updates */
spinlock_t lock;
};
@@ -225,26 +224,10 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
tll->pdata = pdata;
- tll->usbtll_p1_fck = clk_get(dev, "usb_tll_hs_usb_ch0_clk");
- if (IS_ERR(tll->usbtll_p1_fck)) {
- ret = PTR_ERR(tll->usbtll_p1_fck);
- dev_err(dev, "usbtll_p1_fck failed error:%d\n", ret);
- return ret;
- }
-
- tll->usbtll_p2_fck = clk_get(dev, "usb_tll_hs_usb_ch1_clk");
- if (IS_ERR(tll->usbtll_p2_fck)) {
- ret = PTR_ERR(tll->usbtll_p2_fck);
- dev_err(dev, "usbtll_p2_fck failed error:%d\n", ret);
- goto err_p2_fck;
- }
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_request_and_ioremap(dev, res);
- if (!base) {
- ret = -EADDRNOTAVAIL;
- goto err_res;
- }
+ if (!base)
+ return -EADDRNOTAVAIL;
platform_set_drvdata(pdev, tll);
pm_runtime_enable(dev);
@@ -269,6 +252,32 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
break;
}
+ spin_unlock_irqrestore(&tll->lock, flags);
+
+ tll->ch_clk = devm_kzalloc(dev, sizeof(struct clk * [tll->nch]),
+ GFP_KERNEL);
+ if (!tll->ch_clk) {
+ ret = -ENOMEM;
+ dev_err(dev, "Couldn't allocate memory for channel clocks\n");
+ goto err_clk_alloc;
+ }
+
+ spin_lock_irqsave(&tll->lock, flags);
+
+ for (i = 0; i < tll->nch; i++) {
+ char clkname[] = "usb_tll_hs_usb_chx_clk";
+ struct clk *fck;
+
+ snprintf(clkname, sizeof(clkname),
+ "usb_tll_hs_usb_ch%d_clk", i);
+ fck = clk_get(dev, clkname);
+
+ if (IS_ERR(fck))
+ dev_dbg(dev, "can't get clock : %s\n", clkname);
+ else
+ tll->ch_clk[i] = fck;
+ }
+
if (is_ehci_tll_mode(pdata->port_mode[0]) ||
is_ehci_tll_mode(pdata->port_mode[1]) ||
is_ehci_tll_mode(pdata->port_mode[2]) ||
@@ -320,11 +329,9 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
return 0;
-err_res:
- clk_put(tll->usbtll_p2_fck);
-
-err_p2_fck:
- clk_put(tll->usbtll_p1_fck);
+err_clk_alloc:
+ pm_runtime_put_sync(dev);
+ pm_runtime_disable(dev);
return ret;
}
@@ -338,9 +345,11 @@ err_p2_fck:
static int __devexit usbtll_omap_remove(struct platform_device *pdev)
{
struct usbtll_omap *tll = platform_get_drvdata(pdev);
+ int i;
+
+ for (i = 0; i < tll->nch; i++)
+ clk_put(tll->ch_clk[i]);
- clk_put(tll->usbtll_p2_fck);
- clk_put(tll->usbtll_p1_fck);
pm_runtime_disable(&pdev->dev);
return 0;
}
@@ -350,6 +359,7 @@ static int usbtll_runtime_resume(struct device *dev)
struct usbtll_omap *tll = dev_get_drvdata(dev);
struct usbtll_omap_platform_data*pdata = tll->pdata;
unsigned long flags;
+ int i;
dev_dbg(dev, "usbtll_runtime_resume\n");
@@ -360,11 +370,20 @@ static int usbtll_runtime_resume(struct device *dev)
spin_lock_irqsave(&tll->lock, flags);
- if (is_ehci_tll_mode(pdata->port_mode[0]))
- clk_enable(tll->usbtll_p1_fck);
+ for (i = 0; i < tll->nch; i++) {
+ if (is_ehci_tll_mode(pdata->port_mode[i])) {
+ int r;
- if (is_ehci_tll_mode(pdata->port_mode[1]))
- clk_enable(tll->usbtll_p2_fck);
+ if (!tll->ch_clk[i])
+ continue;
+
+ r = clk_enable(tll->ch_clk
[PATCH v4 01/23] mfd: omap-usb-host: get rid of cpu_is_omap..() macros
Instead of using cpu_is_omap..() macros in the device driver we
rely on information provided in the platform data.
The only information we need is whether the USB Host module has
a single ULPI bypass control bit for all ports or individual bypass
control bits for each port. OMAP3 REV2.1 and earlier have the former.
Signed-off-by: Roger Quadros
CC: Tony Lindgren
---
arch/arm/mach-omap2/usb-host.c |4
drivers/mfd/omap-usb-host.c|2 +-
include/linux/platform_data/usb-omap.h |3 +++
3 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index d1dbe12..2e44e8a 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -508,6 +508,10 @@ void __init usbhs_init(const struct usbhs_omap_board_data
*pdata)
if (cpu_is_omap34xx()) {
setup_ehci_io_mux(pdata->port_mode);
setup_ohci_io_mux(pdata->port_mode);
+
+ if (omap_rev() <= OMAP3430_REV_ES2_1)
+ usbhs_data.single_ulpi_bypass = true;
+
} else if (cpu_is_omap44xx()) {
setup_4430ehci_io_mux(pdata->port_mode);
setup_4430ohci_io_mux(pdata->port_mode);
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index cebfe0a..fe7906b 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -384,7 +384,7 @@ static void omap_usbhs_init(struct device *dev)
reg &= ~OMAP_UHH_HOSTCONFIG_P3_CONNECT_STATUS;
/* Bypass the TLL module for PHY mode operation */
- if (cpu_is_omap3430() && (omap_rev() <= OMAP3430_REV_ES2_1)) {
+ if (pdata->single_ulpi_bypass) {
dev_dbg(dev, "OMAP3 ES version <= ES2.1\n");
if (is_ehci_phy_mode(pdata->port_mode[0]) ||
is_ehci_phy_mode(pdata->port_mode[1]) ||
diff --git a/include/linux/platform_data/usb-omap.h
b/include/linux/platform_data/usb-omap.h
index 8570bcf..ef65b67 100644
--- a/include/linux/platform_data/usb-omap.h
+++ b/include/linux/platform_data/usb-omap.h
@@ -59,6 +59,9 @@ struct usbhs_omap_platform_data {
struct ehci_hcd_omap_platform_data *ehci_data;
struct ohci_hcd_omap_platform_data *ohci_data;
+
+ /* OMAP3 <= ES2.1 have a single ulpi bypass control bit */
+ unsignedsingle_ulpi_bypass:1;
};
/*-*/
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 00/23] OMAP USB Host cleanup
Hi, This patchset addresses the following - Avoid addressing clocks one by one by name and use a for loop + bunch of cleanups. - Get number of channels/ports dynamically either from revision register or from platform data. Avoids getting clocks that are not present. - Add OMAP5 and HSIC mode (Not tested) v4: - Added appropriate maintainers in to/cc - minor print message fix in patch 23 to maintain consistency v3: - Rebased on arm-soc/for-next commit f979306c4d38d213c6977aaf3b1115e8ded71e3a - Rearranged patch that get rids of cpu_is_omap..() macros - Coding style fixes v2: - Clocks are allocated dynamically based on number of ports available on the platform - Reduced console spam if non critical clocks are not found on the platform. - Get rid of cpu_is_.. macros from USB host driver. cheers, -roger --- Roger Quadros (23): mfd: omap-usb-host: get rid of cpu_is_omap..() macros mfd: omap-usb-tll: Avoid creating copy of platform data mfd: omap-usb-tll: Fix channel count detection mfd: omap-usb-tll: Use devm_kzalloc/ioremap and clean up error path mfd: omap-usb-tll: Clean up clock handling mfd: omap-usb-tll: introduce and use mode_needs_tll() mfd: omap-usb-tll: Check for missing platform data in probe mfd: omap-usb-tll: Fix error message mfd: omap-usb-tll: serialize access to TLL device mfd: omap-usb-tll: Add OMAP5 revision and HSIC support mfd: omap_usb_host: Avoid creating copy of platform_data mfd: omap-usb-host: Use devm_kzalloc() and devm_request_and_ioremap() mfd: omap-usb-host: know about number of ports from revision register mfd: omap-usb-host: override number of ports from platform data mfd: omap-usb-host: cleanup clock management code ARM: OMAP2+: clock data: Merge utmi_px_gfclk into usb_host_hs_utmi_px_clk mfd: omap-usb-host: Manage HSIC clocks for HSIC mode mfd: omap-usb-host: Get rid of unnecessary spinlock mfd: omap-usb-host: clean up omap_usbhs_init() USB: ehci-omap: Don't free gpios that we didn't request ARM: OMAP3: clock data: get rid of unused USB host clock aliases and dummies ARM: OMAP4: clock data: get rid of unused USB host clock aliases mfd: omap-usb-host: Don't spam console on clk_set_parent failure arch/arm/mach-omap2/cclock3xxx_data.c | 13 - arch/arm/mach-omap2/cclock44xx_data.c | 55 +++-- arch/arm/mach-omap2/usb-host.c |5 + arch/arm/mach-omap2/usb.h |1 + drivers/mfd/omap-usb-host.c| 474 ++-- drivers/mfd/omap-usb-tll.c | 244 + drivers/usb/host/ehci-omap.c |8 - include/linux/platform_data/usb-omap.h |4 + 8 files changed, 451 insertions(+), 353 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 04/23] mfd: omap-usb-tll: Use devm_kzalloc/ioremap and clean up error path
Use devm_ variants of kzalloc() and ioremap(). Simplify the error path.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-tll.c | 37 +++--
1 files changed, 11 insertions(+), 26 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index e67cafc..828207f 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -215,11 +215,10 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
dev_dbg(dev, "starting TI HSUSB TLL Controller\n");
- tll = kzalloc(sizeof(struct usbtll_omap), GFP_KERNEL);
+ tll = devm_kzalloc(dev, sizeof(struct usbtll_omap), GFP_KERNEL);
if (!tll) {
dev_err(dev, "Memory allocation failed\n");
- ret = -ENOMEM;
- goto end;
+ return -ENOMEM;
}
spin_lock_init(&tll->lock);
@@ -230,28 +229,21 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
if (IS_ERR(tll->usbtll_p1_fck)) {
ret = PTR_ERR(tll->usbtll_p1_fck);
dev_err(dev, "usbtll_p1_fck failed error:%d\n", ret);
- goto err_tll;
+ return ret;
}
tll->usbtll_p2_fck = clk_get(dev, "usb_tll_hs_usb_ch1_clk");
if (IS_ERR(tll->usbtll_p2_fck)) {
ret = PTR_ERR(tll->usbtll_p2_fck);
dev_err(dev, "usbtll_p2_fck failed error:%d\n", ret);
- goto err_usbtll_p1_fck;
+ goto err_p2_fck;
}
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(dev, "usb tll get resource failed\n");
- ret = -ENODEV;
- goto err_usbtll_p2_fck;
- }
-
- base = ioremap(res->start, resource_size(res));
+ base = devm_request_and_ioremap(dev, res);
if (!base) {
- dev_err(dev, "TLL ioremap failed\n");
- ret = -ENOMEM;
- goto err_usbtll_p2_fck;
+ ret = -EADDRNOTAVAIL;
+ goto err_res;
}
platform_set_drvdata(pdev, tll);
@@ -323,23 +315,17 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
}
spin_unlock_irqrestore(&tll->lock, flags);
- iounmap(base);
pm_runtime_put_sync(dev);
tll_pdev = pdev;
- if (!ret)
- goto end;
- pm_runtime_disable(dev);
-err_usbtll_p2_fck:
+ return 0;
+
+err_res:
clk_put(tll->usbtll_p2_fck);
-err_usbtll_p1_fck:
+err_p2_fck:
clk_put(tll->usbtll_p1_fck);
-err_tll:
- kfree(tll);
-
-end:
return ret;
}
@@ -356,7 +342,6 @@ static int __devexit usbtll_omap_remove(struct
platform_device *pdev)
clk_put(tll->usbtll_p2_fck);
clk_put(tll->usbtll_p1_fck);
pm_runtime_disable(&pdev->dev);
- kfree(tll);
return 0;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 10/23] mfd: omap-usb-tll: Add OMAP5 revision and HSIC support
The TLL module on OMAP5 has 3 channels.
HSIC mode requires the TLL channel to be in Transparent UTMI mode.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-tll.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 7b4afd0..ecc6a62 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -54,10 +54,13 @@
#defineOMAP_TLL_CHANNEL_CONF(num) (0x040 + 0x004
* num)
#define OMAP_TLL_CHANNEL_CONF_FSLSMODE_SHIFT 24
+#define OMAP_TLL_CHANNEL_CONF_DRVVBUS (1 << 16)
+#define OMAP_TLL_CHANNEL_CONF_CHRGVBUS (1 << 15)
#defineOMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF(1 << 11)
#defineOMAP_TLL_CHANNEL_CONF_ULPI_ULPIAUTOIDLE (1 << 10)
#defineOMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE (1 << 9)
#defineOMAP_TLL_CHANNEL_CONF_ULPIDDRMODE (1 << 8)
+#define OMAP_TLL_CHANNEL_CONF_MODE_TRANSPARENT_UTMI(2 << 1)
#define OMAP_TLL_CHANNEL_CONF_CHANMODE_FSLS(1 << 1)
#defineOMAP_TLL_CHANNEL_CONF_CHANEN(1 << 0)
@@ -92,6 +95,7 @@
#define OMAP_USBTLL_REV1 0x0015 /* OMAP3 */
#define OMAP_USBTLL_REV2 0x0018 /* OMAP 3630 */
#define OMAP_USBTLL_REV3 0x0004 /* OMAP4 */
+#define OMAP_USBTLL_REV4 0x0006 /* OMAP5 */
#define is_ehci_tll_mode(x)(x == OMAP_EHCI_PORT_MODE_TLL)
@@ -242,6 +246,7 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
ver = usbtll_read(base, OMAP_USBTLL_REVISION);
switch (ver) {
case OMAP_USBTLL_REV1:
+ case OMAP_USBTLL_REV4:
tll->nch = OMAP_TLL_CHANNEL_COUNT;
break;
case OMAP_USBTLL_REV2:
@@ -310,6 +315,15 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
reg &= ~(OMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE
| OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF
| OMAP_TLL_CHANNEL_CONF_ULPIDDRMODE);
+ } else if (pdata->port_mode[i] ==
+ OMAP_EHCI_PORT_MODE_HSIC) {
+ /*
+* HSIC Mode requires UTMI port configurations
+*/
+ reg |= OMAP_TLL_CHANNEL_CONF_DRVVBUS
+| OMAP_TLL_CHANNEL_CONF_CHRGVBUS
+| OMAP_TLL_CHANNEL_CONF_MODE_TRANSPARENT_UTMI
+| OMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF;
} else {
continue;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 09/23] mfd: omap-usb-tll: serialize access to TLL device
Get rid of the unnecessary spin_lock_irqsave/restore() as there is
no interrupt handler for this driver. Instead we serialize access
to tll_dev using a global spinlock.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-tll.c | 53 ++-
1 files changed, 27 insertions(+), 26 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 38d0532..7b4afd0 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -103,14 +103,13 @@ struct usbtll_omap {
int nch;/* num. of channels */
struct usbtll_omap_platform_data*pdata;
struct clk **ch_clk;
- /* secure the register updates */
- spinlock_t lock;
};
/*-*/
static const char usbtll_driver_name[] = USBTLL_DRIVER_NAME;
static struct device *tll_dev;
+static DEFINE_SPINLOCK(tll_lock); /* serialize access to tll_dev */
/*-*/
@@ -212,7 +211,6 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
struct resource *res;
struct usbtll_omap *tll;
unsignedreg;
- unsigned long flags;
int ret = 0;
int i, ver;
bool needs_tll;
@@ -230,8 +228,6 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
return -ENODEV;
}
- spin_lock_init(&tll->lock);
-
tll->pdata = pdata;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -243,8 +239,6 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
- spin_lock_irqsave(&tll->lock, flags);
-
ver = usbtll_read(base, OMAP_USBTLL_REVISION);
switch (ver) {
case OMAP_USBTLL_REV1:
@@ -262,8 +256,6 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
break;
}
- spin_unlock_irqrestore(&tll->lock, flags);
-
tll->ch_clk = devm_kzalloc(dev, sizeof(struct clk * [tll->nch]),
GFP_KERNEL);
if (!tll->ch_clk) {
@@ -272,8 +264,6 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
goto err_clk_alloc;
}
- spin_lock_irqsave(&tll->lock, flags);
-
for (i = 0; i < tll->nch; i++) {
char clkname[] = "usb_tll_hs_usb_chx_clk";
struct clk *fck;
@@ -332,10 +322,11 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
}
}
- spin_unlock_irqrestore(&tll->lock, flags);
pm_runtime_put_sync(dev);
/* only after this can omap_tll_enable/disable work */
+ spin_lock(&tll_lock);
tll_dev = dev;
+ spin_unlock(&tll_lock);
return 0;
@@ -357,7 +348,9 @@ static int __devexit usbtll_omap_remove(struct
platform_device *pdev)
struct usbtll_omap *tll = platform_get_drvdata(pdev);
int i;
+ spin_lock(&tll_lock);
tll_dev = NULL;
+ spin_unlock(&tll_lock);
for (i = 0; i < tll->nch; i++)
clk_put(tll->ch_clk[i]);
@@ -370,13 +363,10 @@ static int usbtll_runtime_resume(struct device *dev)
{
struct usbtll_omap *tll = dev_get_drvdata(dev);
struct usbtll_omap_platform_data*pdata = tll->pdata;
- unsigned long flags;
int i;
dev_dbg(dev, "usbtll_runtime_resume\n");
- spin_lock_irqsave(&tll->lock, flags);
-
for (i = 0; i < tll->nch; i++) {
if (omap_usb_mode_needs_tll(pdata->port_mode[i])) {
int r;
@@ -392,8 +382,6 @@ static int usbtll_runtime_resume(struct device *dev)
}
}
- spin_unlock_irqrestore(&tll->lock, flags);
-
return 0;
}
@@ -401,13 +389,10 @@ static int usbtll_runtime_suspend(struct device *dev)
{
struct usbtll_omap *tll = dev_get_drvdata(dev);
struct usbtll_omap_platform_data*pdata = tll->pdata;
- unsigned long flags;
int i;
dev_dbg(dev, "usbtll_runtime_suspend\n");
- spin_lock_irqsave(&tll->lock, flags);
-
for (i = 0; i < tll->nch; i++) {
if (omap_usb_mode_needs_tll(pdata->port_mode[i])) {
if (tll->ch_clk[i])
@@ -415,8 +400,6 @@ static int usbtll_runtime_suspend(struct device *dev)
}
}
- spin_unlock_irqrestore(&tll->lock, flags);
-
[PATCH v4 11/23] mfd: omap_usb_host: Avoid creating copy of platform_data
We can just hold the pointer to the platform data instead
of creating a copy of it.
Also get rid of the unnecessary missing platform data checks
in runtime_suspend/resume. We are already checking for missing
platform data in probe.
Signed-off-by: Roger Quadros
Acked-by: Felipe Balbi
---
drivers/mfd/omap-usb-host.c | 30 --
1 files changed, 8 insertions(+), 22 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index fe7906b..8b8f1da 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -103,7 +103,7 @@ struct usbhs_hcd_omap {
void __iomem*uhh_base;
- struct usbhs_omap_platform_data platdata;
+ struct usbhs_omap_platform_data *pdata;
u32 usbhs_rev;
spinlock_t lock;
@@ -195,8 +195,8 @@ static int omap_usbhs_alloc_children(struct platform_device
*pdev)
int ret;
omap = platform_get_drvdata(pdev);
- ehci_data = omap->platdata.ehci_data;
- ohci_data = omap->platdata.ohci_data;
+ ehci_data = omap->pdata->ehci_data;
+ ohci_data = omap->pdata->ohci_data;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ehci");
if (!res) {
@@ -279,16 +279,11 @@ static bool is_ohci_port(enum usbhs_omap_port_mode pmode)
static int usbhs_runtime_resume(struct device *dev)
{
struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
- struct usbhs_omap_platform_data *pdata = &omap->platdata;
unsigned long flags;
+ struct usbhs_omap_platform_data *pdata = omap->pdata;
dev_dbg(dev, "usbhs_runtime_resume\n");
- if (!pdata) {
- dev_dbg(dev, "missing platform_data\n");
- return -ENODEV;
- }
-
omap_tll_enable();
spin_lock_irqsave(&omap->lock, flags);
@@ -311,16 +306,11 @@ static int usbhs_runtime_resume(struct device *dev)
static int usbhs_runtime_suspend(struct device *dev)
{
struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
- struct usbhs_omap_platform_data *pdata = &omap->platdata;
unsigned long flags;
+ struct usbhs_omap_platform_data *pdata = omap->pdata;
dev_dbg(dev, "usbhs_runtime_suspend\n");
- if (!pdata) {
- dev_dbg(dev, "missing platform_data\n");
- return -ENODEV;
- }
-
spin_lock_irqsave(&omap->lock, flags);
if (is_ehci_tll_mode(pdata->port_mode[0]))
@@ -343,7 +333,7 @@ static int usbhs_runtime_suspend(struct device *dev)
static void omap_usbhs_init(struct device *dev)
{
struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
- struct usbhs_omap_platform_data *pdata = &omap->platdata;
+ struct usbhs_omap_platform_data *pdata = omap->pdata;
unsigned long flags;
unsignedreg;
@@ -450,7 +440,7 @@ static void omap_usbhs_init(struct device *dev)
static void omap_usbhs_deinit(struct device *dev)
{
struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
- struct usbhs_omap_platform_data *pdata = &omap->platdata;
+ struct usbhs_omap_platform_data *pdata = omap->pdata;
if (pdata->ehci_data->phy_reset) {
if (gpio_is_valid(pdata->ehci_data->reset_gpio_port[0]))
@@ -491,11 +481,7 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
spin_lock_init(&omap->lock);
- for (i = 0; i < OMAP3_HS_USB_PORTS; i++)
- omap->platdata.port_mode[i] = pdata->port_mode[i];
-
- omap->platdata.ehci_data = pdata->ehci_data;
- omap->platdata.ohci_data = pdata->ohci_data;
+ omap->pdata = pdata;
pm_runtime_enable(dev);
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 08/23] mfd: omap-usb-tll: Fix error message
omap_enable/disable_tll() can fail if TLL device is not
initialized. It could be due to multiple reasons and not only
due to missing platform data.
Also make local variables static and use 'struct device *'
instead of 'struct platform_device *' for global reference.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-tll.c | 21 -
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 8b596e0..38d0532 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -109,8 +109,8 @@ struct usbtll_omap {
/*-*/
-const char usbtll_driver_name[] = USBTLL_DRIVER_NAME;
-struct platform_device *tll_pdev;
+static const char usbtll_driver_name[] = USBTLL_DRIVER_NAME;
+static struct device *tll_dev;
/*-*/
@@ -334,7 +334,8 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
spin_unlock_irqrestore(&tll->lock, flags);
pm_runtime_put_sync(dev);
- tll_pdev = pdev;
+ /* only after this can omap_tll_enable/disable work */
+ tll_dev = dev;
return 0;
@@ -356,6 +357,8 @@ static int __devexit usbtll_omap_remove(struct
platform_device *pdev)
struct usbtll_omap *tll = platform_get_drvdata(pdev);
int i;
+ tll_dev = NULL;
+
for (i = 0; i < tll->nch; i++)
clk_put(tll->ch_clk[i]);
@@ -435,21 +438,21 @@ static struct platform_driver usbtll_omap_driver = {
int omap_tll_enable(void)
{
- if (!tll_pdev) {
- pr_err("missing omap usbhs tll platform_data\n");
+ if (!tll_dev) {
+ pr_err("%s: OMAP USB TLL not initialized\n", __func__);
return -ENODEV;
}
- return pm_runtime_get_sync(&tll_pdev->dev);
+ return pm_runtime_get_sync(tll_dev);
}
EXPORT_SYMBOL_GPL(omap_tll_enable);
int omap_tll_disable(void)
{
- if (!tll_pdev) {
- pr_err("missing omap usbhs tll platform_data\n");
+ if (!tll_dev) {
+ pr_err("%s: OMAP USB TLL not initialized\n", __func__);
return -ENODEV;
}
- return pm_runtime_put_sync(&tll_pdev->dev);
+ return pm_runtime_put_sync(tll_dev);
}
EXPORT_SYMBOL_GPL(omap_tll_disable);
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 07/23] mfd: omap-usb-tll: Check for missing platform data in probe
No need to check for missing platform data in runtime_suspend/resume
as it makes more sense to do it in the probe function.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-tll.c | 15 +--
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 07370a3..8b596e0 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -225,6 +225,11 @@ static int __devinit usbtll_omap_probe(struct
platform_device *pdev)
return -ENOMEM;
}
+ if (!pdata) {
+ dev_err(dev, "Platform data missing\n");
+ return -ENODEV;
+ }
+
spin_lock_init(&tll->lock);
tll->pdata = pdata;
@@ -367,11 +372,6 @@ static int usbtll_runtime_resume(struct device *dev)
dev_dbg(dev, "usbtll_runtime_resume\n");
- if (!pdata) {
- dev_dbg(dev, "missing platform_data\n");
- return -ENODEV;
- }
-
spin_lock_irqsave(&tll->lock, flags);
for (i = 0; i < tll->nch; i++) {
@@ -403,11 +403,6 @@ static int usbtll_runtime_suspend(struct device *dev)
dev_dbg(dev, "usbtll_runtime_suspend\n");
- if (!pdata) {
- dev_dbg(dev, "missing platform_data\n");
- return -ENODEV;
- }
-
spin_lock_irqsave(&tll->lock, flags);
for (i = 0; i < tll->nch; i++) {
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 13/23] mfd: omap-usb-host: know about number of ports from revision register
The revision register should tell us how many ports are present.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 32 +++-
1 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 13a3e8c..9c23a08 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -92,6 +92,8 @@
struct usbhs_hcd_omap {
+ int nports;
+
struct clk *xclk60mhsp1_ck;
struct clk *xclk60mhsp2_ck;
struct clk *utmi_p1_fck;
@@ -354,8 +356,6 @@ static void omap_usbhs_init(struct device *dev)
pm_runtime_get_sync(dev);
spin_lock_irqsave(&omap->lock, flags);
- omap->usbhs_rev = usbhs_read(omap->uhh_base, OMAP_UHH_REVISION);
- dev_dbg(dev, "OMAP UHH_REVISION 0x%x\n", omap->usbhs_rev);
reg = usbhs_read(omap->uhh_base, OMAP_UHH_HOSTCONFIG);
/* setup ULPI bypass and burst configurations */
@@ -488,8 +488,32 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
pm_runtime_enable(dev);
+ platform_set_drvdata(pdev, omap);
+ pm_runtime_get_sync(dev);
- for (i = 0; i < OMAP3_HS_USB_PORTS; i++)
+ omap->usbhs_rev = usbhs_read(omap->uhh_base, OMAP_UHH_REVISION);
+
+ /* we need to call runtime suspend before we update omap->nports
+* to prevent unbalanced clk_disable()
+*/
+ pm_runtime_put_sync(dev);
+
+ switch (omap->usbhs_rev) {
+ case OMAP_USBHS_REV1:
+ omap->nports = 3;
+ break;
+ case OMAP_USBHS_REV2:
+ omap->nports = 2;
+ break;
+ default:
+ omap->nports = OMAP3_HS_USB_PORTS;
+ dev_dbg(dev,
+ "USB HOST Rev : 0x%d not recognized, assuming %d ports\n",
+ omap->usbhs_rev, omap->nports);
+ break;
+ }
+
+ for (i = 0; i < omap->nports; i++)
if (is_ehci_phy_mode(i) || is_ehci_tll_mode(i) ||
is_ehci_hsic_mode(i)) {
omap->ehci_logic_fck = clk_get(dev, "ehci_logic_fck");
@@ -579,8 +603,6 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
"failed error:%d\n", ret);
}
- platform_set_drvdata(pdev, omap);
-
omap_usbhs_init(dev);
ret = omap_usbhs_alloc_children(pdev);
if (ret) {
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 17/23] mfd: omap-usb-host: Manage HSIC clocks for HSIC mode
Enable the optional HSIC clocks (60MHz and 480MHz) for the ports
that are configured in HSIC mode.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 77 +++---
1 files changed, 71 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 6294f13..90dbd17 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -94,6 +94,8 @@
struct usbhs_hcd_omap {
int nports;
struct clk **utmi_clk;
+ struct clk **hsic60m_clk;
+ struct clk **hsic480m_clk;
struct clk *xclk60mhsp1_ck;
struct clk *xclk60mhsp2_ck;
@@ -291,7 +293,28 @@ static int usbhs_runtime_resume(struct device *dev)
clk_enable(omap->ehci_logic_fck);
for (i = 0; i < omap->nports; i++) {
- if (is_ehci_tll_mode(pdata->port_mode[i])) {
+ switch (pdata->port_mode[i]) {
+ case OMAP_EHCI_PORT_MODE_HSIC:
+ if (omap->hsic60m_clk[i]) {
+ r = clk_enable(omap->hsic60m_clk[i]);
+ if (r) {
+ dev_err(dev,
+"Can't enable port %d hsic60m
clk:%d\n",
+i, r);
+ }
+ }
+
+ if (omap->hsic480m_clk[i]) {
+ r = clk_enable(omap->hsic480m_clk[i]);
+ if (r) {
+ dev_err(dev,
+"Can't enable port %d hsic480m
clk:%d\n",
+i, r);
+ }
+ }
+ /* Fall through as HSIC mode needs utmi_clk */
+
+ case OMAP_EHCI_PORT_MODE_TLL:
if (omap->utmi_clk[i]) {
r = clk_enable(omap->utmi_clk[i]);
if (r) {
@@ -300,6 +323,9 @@ static int usbhs_runtime_resume(struct device *dev)
i, r);
}
}
+ break;
+ default:
+ break;
}
}
@@ -320,9 +346,21 @@ static int usbhs_runtime_suspend(struct device *dev)
spin_lock_irqsave(&omap->lock, flags);
for (i = 0; i < omap->nports; i++) {
- if (is_ehci_tll_mode(pdata->port_mode[i])) {
+ switch (pdata->port_mode[i]) {
+ case OMAP_EHCI_PORT_MODE_HSIC:
+ if (omap->hsic60m_clk[i])
+ clk_disable(omap->hsic60m_clk[i]);
+
+ if (omap->hsic480m_clk[i])
+ clk_disable(omap->hsic480m_clk[i]);
+ /* Fall through as utmi_clks were used in HSIC mode */
+
+ case OMAP_EHCI_PORT_MODE_TLL:
if (omap->utmi_clk[i])
clk_disable(omap->utmi_clk[i]);
+ break;
+ default:
+ break;
}
}
@@ -527,7 +565,10 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
i = sizeof(struct clk *) * omap->nports;
omap->utmi_clk = devm_kzalloc(dev, i, GFP_KERNEL);
- if (!omap->utmi_clk) {
+ omap->hsic480m_clk = devm_kzalloc(dev, i, GFP_KERNEL);
+ omap->hsic60m_clk = devm_kzalloc(dev, i, GFP_KERNEL);
+
+ if (!omap->utmi_clk || !omap->hsic480m_clk || !omap->hsic60m_clk) {
dev_err(dev, "Memory allocation failed\n");
ret = -ENOMEM;
goto err_mem;
@@ -571,7 +612,7 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
for (i = 0; i < omap->nports; i++) {
struct clk *pclk;
- char clkname[] = "usb_host_hs_utmi_px_clk";
+ char clkname[] = "usb_host_hs_hsic480m_px_clk";
/* clock names are indexed from 1*/
snprintf(clkname, sizeof(clkname),
@@ -587,6 +628,24 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
clkname, PTR_ERR(pclk));
else
omap->utmi_clk[i] = pclk;
+
+ snprintf(clkname, sizeof(clkname),
+ "usb_host_hs_hsic480m_p%d_clk", i + 1);
+ pclk = clk_get(dev, clkname);
+ if (IS_ERR(pclk))
+ dev_dbg(dev, "Failed to get clock : %s : %ld\n",
+ clkname, PTR_ERR(pclk));
+ else
+ omap->hsic480m_clk[i] = pc
[PATCH v4 19/23] mfd: omap-usb-host: clean up omap_usbhs_init()
We split initializing revision 1 and revision 2 into different
functions. Initialization is now done dynamically so that only
the number of ports available on the system are initialized.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 122 +-
1 files changed, 73 insertions(+), 49 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 289b356..0bb54393 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -363,6 +363,75 @@ static int usbhs_runtime_suspend(struct device *dev)
return 0;
}
+static unsigned omap_usbhs_rev1_hostconfig(struct usbhs_hcd_omap *omap,
+ unsigned reg)
+{
+ struct usbhs_omap_platform_data *pdata = omap->pdata;
+ int i;
+
+ for (i = 0; i < omap->nports; i++) {
+ switch (pdata->port_mode[i]) {
+ case OMAP_USBHS_PORT_MODE_UNUSED:
+ reg &= ~(OMAP_UHH_HOSTCONFIG_P1_CONNECT_STATUS << i);
+ break;
+ case OMAP_EHCI_PORT_MODE_PHY:
+ if (pdata->single_ulpi_bypass)
+ break;
+
+ if (i == 0)
+ reg &= ~OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS;
+ else
+ reg &= ~(OMAP_UHH_HOSTCONFIG_ULPI_P2_BYPASS
+ << (i-1));
+ break;
+ default:
+ if (pdata->single_ulpi_bypass)
+ break;
+
+ if (i == 0)
+ reg |= OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS;
+ else
+ reg |= OMAP_UHH_HOSTCONFIG_ULPI_P2_BYPASS
+ << (i-1);
+ break;
+ }
+ }
+
+ if (pdata->single_ulpi_bypass) {
+ /* bypass ULPI only if none of the ports use PHY mode */
+ reg |= OMAP_UHH_HOSTCONFIG_ULPI_BYPASS;
+
+ for (i = 0; i < omap->nports; i++) {
+ if (is_ehci_phy_mode(pdata->port_mode[i])) {
+ reg &= OMAP_UHH_HOSTCONFIG_ULPI_BYPASS;
+ break;
+ }
+ }
+ }
+
+ return reg;
+}
+
+static unsigned omap_usbhs_rev2_hostconfig(struct usbhs_hcd_omap *omap,
+ unsigned reg)
+{
+ struct usbhs_omap_platform_data *pdata = omap->pdata;
+ int i;
+
+ for (i = 0; i < omap->nports; i++) {
+ /* Clear port mode fields for PHY mode */
+ reg &= ~(OMAP4_P1_MODE_CLEAR << 2 * i);
+
+ if (is_ehci_tll_mode(pdata->port_mode[i]) ||
+ (is_ohci_port(pdata->port_mode[i])))
+ reg |= OMAP4_P1_MODE_TLL << 2 * i;
+ else if (is_ehci_hsic_mode(pdata->port_mode[i]))
+ reg |= OMAP4_P1_MODE_HSIC << 2 * i;
+ }
+
+ return reg;
+}
+
static void omap_usbhs_init(struct device *dev)
{
struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
@@ -394,55 +463,10 @@ static void omap_usbhs_init(struct device *dev)
reg |= OMAP4_UHH_HOSTCONFIG_APP_START_CLK;
reg &= ~OMAP_UHH_HOSTCONFIG_INCRX_ALIGN_EN;
- if (is_omap_usbhs_rev1(omap)) {
- if (pdata->port_mode[0] == OMAP_USBHS_PORT_MODE_UNUSED)
- reg &= ~OMAP_UHH_HOSTCONFIG_P1_CONNECT_STATUS;
- if (pdata->port_mode[1] == OMAP_USBHS_PORT_MODE_UNUSED)
- reg &= ~OMAP_UHH_HOSTCONFIG_P2_CONNECT_STATUS;
- if (pdata->port_mode[2] == OMAP_USBHS_PORT_MODE_UNUSED)
- reg &= ~OMAP_UHH_HOSTCONFIG_P3_CONNECT_STATUS;
-
- /* Bypass the TLL module for PHY mode operation */
- if (pdata->single_ulpi_bypass) {
- dev_dbg(dev, "OMAP3 ES version <= ES2.1\n");
- if (is_ehci_phy_mode(pdata->port_mode[0]) ||
- is_ehci_phy_mode(pdata->port_mode[1]) ||
- is_ehci_phy_mode(pdata->port_mode[2]))
- reg &= ~OMAP_UHH_HOSTCONFIG_ULPI_BYPASS;
- else
- reg |= OMAP_UHH_HOSTCONFIG_ULPI_BYPASS;
- } else {
- dev_dbg(dev, "OMAP3 ES version > ES2.1\n");
- if (is_ehci_phy_mode(pdata->port_mode[0]))
- reg &= ~OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS;
- else
- reg |= OMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS;
- if (is_ehci_phy_mode(pdata->port_mode[1]))
-
[PATCH v4 15/23] mfd: omap-usb-host: cleanup clock management code
All ports have similarly named port clocks so we can
bunch them into a port data structure and use for loop
to enable/disable the clocks.
Dynamically allocate and get clocks based on number of ports
available on the platform
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 159 ++-
1 files changed, 80 insertions(+), 79 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 714b2f1..6294f13 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -93,13 +93,10 @@
struct usbhs_hcd_omap {
int nports;
+ struct clk **utmi_clk;
struct clk *xclk60mhsp1_ck;
struct clk *xclk60mhsp2_ck;
- struct clk *utmi_p1_fck;
- struct clk *usbhost_p1_fck;
- struct clk *utmi_p2_fck;
- struct clk *usbhost_p2_fck;
struct clk *init_60m_fclk;
struct clk *ehci_logic_fck;
@@ -283,6 +280,7 @@ static int usbhs_runtime_resume(struct device *dev)
struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
unsigned long flags;
struct usbhs_omap_platform_data *pdata = omap->pdata;
+ int i, r;
dev_dbg(dev, "usbhs_runtime_resume\n");
@@ -292,13 +290,18 @@ static int usbhs_runtime_resume(struct device *dev)
if (omap->ehci_logic_fck && !IS_ERR(omap->ehci_logic_fck))
clk_enable(omap->ehci_logic_fck);
- if (is_ehci_tll_mode(pdata->port_mode[0]))
- clk_enable(omap->usbhost_p1_fck);
- if (is_ehci_tll_mode(pdata->port_mode[1]))
- clk_enable(omap->usbhost_p2_fck);
-
- clk_enable(omap->utmi_p1_fck);
- clk_enable(omap->utmi_p2_fck);
+ for (i = 0; i < omap->nports; i++) {
+ if (is_ehci_tll_mode(pdata->port_mode[i])) {
+ if (omap->utmi_clk[i]) {
+ r = clk_enable(omap->utmi_clk[i]);
+ if (r) {
+ dev_err(dev,
+"Can't enable port %d clk : %d\n",
+i, r);
+ }
+ }
+ }
+ }
spin_unlock_irqrestore(&omap->lock, flags);
@@ -310,18 +313,18 @@ static int usbhs_runtime_suspend(struct device *dev)
struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
unsigned long flags;
struct usbhs_omap_platform_data *pdata = omap->pdata;
+ int i;
dev_dbg(dev, "usbhs_runtime_suspend\n");
spin_lock_irqsave(&omap->lock, flags);
- if (is_ehci_tll_mode(pdata->port_mode[0]))
- clk_disable(omap->usbhost_p1_fck);
- if (is_ehci_tll_mode(pdata->port_mode[1]))
- clk_disable(omap->usbhost_p2_fck);
-
- clk_disable(omap->utmi_p2_fck);
- clk_disable(omap->utmi_p1_fck);
+ for (i = 0; i < omap->nports; i++) {
+ if (is_ehci_tll_mode(pdata->port_mode[i])) {
+ if (omap->utmi_clk[i])
+ clk_disable(omap->utmi_clk[i]);
+ }
+ }
if (omap->ehci_logic_fck && !IS_ERR(omap->ehci_logic_fck))
clk_disable(omap->ehci_logic_fck);
@@ -465,6 +468,7 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
struct resource *res;
int ret = 0;
int i;
+ boolneed_logic_fck;
if (!pdata) {
dev_err(dev, "Missing platform data\n");
@@ -521,76 +525,79 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
}
}
- for (i = 0; i < omap->nports; i++)
+ i = sizeof(struct clk *) * omap->nports;
+ omap->utmi_clk = devm_kzalloc(dev, i, GFP_KERNEL);
+ if (!omap->utmi_clk) {
+ dev_err(dev, "Memory allocation failed\n");
+ ret = -ENOMEM;
+ goto err_mem;
+ }
+
+ need_logic_fck = false;
+ for (i = 0; i < omap->nports; i++) {
if (is_ehci_phy_mode(i) || is_ehci_tll_mode(i) ||
- is_ehci_hsic_mode(i)) {
- omap->ehci_logic_fck = clk_get(dev, "ehci_logic_fck");
- if (IS_ERR(omap->ehci_logic_fck)) {
- ret = PTR_ERR(omap->ehci_logic_fck);
- dev_warn(dev, "ehci_logic_fck failed:%d\n",
-ret);
- }
- break;
- }
+ is_ehci_hsic_
[PATCH v4 14/23] mfd: omap-usb-host: override number of ports from platform data
Both OMAP4 and 5 exhibit the same revision ID in the REVISION register
but they have different number of ports i.e. 2 and 3 respectively.
So we can't rely on REVISION register for number of ports on OMAP5
and depend on platform data (or device tree) instead.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/usb-host.c |1 +
arch/arm/mach-omap2/usb.h |1 +
drivers/mfd/omap-usb-host.c| 34 +++
include/linux/platform_data/usb-omap.h |1 +
4 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 2e44e8a..ee8c473 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -504,6 +504,7 @@ void __init usbhs_init(const struct usbhs_omap_board_data
*pdata)
ohci_data.es2_compatibility = pdata->es2_compatibility;
usbhs_data.ehci_data = &ehci_data;
usbhs_data.ohci_data = &ohci_data;
+ usbhs_data.nports = pdata->nports;
if (cpu_is_omap34xx()) {
setup_ehci_io_mux(pdata->port_mode);
diff --git a/arch/arm/mach-omap2/usb.h b/arch/arm/mach-omap2/usb.h
index 9b986ea..7dc0f04 100644
--- a/arch/arm/mach-omap2/usb.h
+++ b/arch/arm/mach-omap2/usb.h
@@ -54,6 +54,7 @@
#define USBPHY_DATA_POLARITY (1 << 23)
struct usbhs_omap_board_data {
+ int nports;
enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
/* have to be valid if phy_reset is true and portx is in phy mode */
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 9c23a08..714b2f1 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -498,19 +498,27 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
*/
pm_runtime_put_sync(dev);
- switch (omap->usbhs_rev) {
- case OMAP_USBHS_REV1:
- omap->nports = 3;
- break;
- case OMAP_USBHS_REV2:
- omap->nports = 2;
- break;
- default:
- omap->nports = OMAP3_HS_USB_PORTS;
- dev_dbg(dev,
- "USB HOST Rev : 0x%d not recognized, assuming %d ports\n",
- omap->usbhs_rev, omap->nports);
- break;
+ /*
+* If platform data contains nports then use that
+* else make out number of ports from USBHS revision
+*/
+ if (pdata->nports) {
+ omap->nports = pdata->nports;
+ } else {
+ switch (omap->usbhs_rev) {
+ case OMAP_USBHS_REV1:
+ omap->nports = 3;
+ break;
+ case OMAP_USBHS_REV2:
+ omap->nports = 2;
+ break;
+ default:
+ omap->nports = OMAP3_HS_USB_PORTS;
+ dev_dbg(dev,
+ "USB HOST Rev:0x%d not recognized, assuming %d ports\n",
+ omap->usbhs_rev, omap->nports);
+ break;
+ }
}
for (i = 0; i < omap->nports; i++)
diff --git a/include/linux/platform_data/usb-omap.h
b/include/linux/platform_data/usb-omap.h
index ef65b67..57707c7 100644
--- a/include/linux/platform_data/usb-omap.h
+++ b/include/linux/platform_data/usb-omap.h
@@ -55,6 +55,7 @@ struct ohci_hcd_omap_platform_data {
};
struct usbhs_omap_platform_data {
+ int nports;
enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
struct ehci_hcd_omap_platform_data *ehci_data;
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 12/23] mfd: omap-usb-host: Use devm_kzalloc() and devm_request_and_ioremap()
Use devm_ variants of kzalloc and ioremap. Also clean up error path.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 36 +---
1 files changed, 9 insertions(+), 27 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 8b8f1da..13a3e8c 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -468,17 +468,20 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
if (!pdata) {
dev_err(dev, "Missing platform data\n");
- ret = -ENOMEM;
- goto end_probe;
+ return -ENODEV;
}
- omap = kzalloc(sizeof(*omap), GFP_KERNEL);
+ omap = devm_kzalloc(dev, sizeof(*omap), GFP_KERNEL);
if (!omap) {
dev_err(dev, "Memory allocation failed\n");
- ret = -ENOMEM;
- goto end_probe;
+ return -ENOMEM;
}
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "uhh");
+ omap->uhh_base = devm_request_and_ioremap(dev, res);
+ if (!omap->uhh_base)
+ return -EADDRNOTAVAIL;
+
spin_lock_init(&omap->lock);
omap->pdata = pdata;
@@ -576,20 +579,6 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
"failed error:%d\n", ret);
}
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "uhh");
- if (!res) {
- dev_err(dev, "UHH EHCI get resource failed\n");
- ret = -ENODEV;
- goto err_init_60m_fclk;
- }
-
- omap->uhh_base = ioremap(res->start, resource_size(res));
- if (!omap->uhh_base) {
- dev_err(dev, "UHH ioremap failed\n");
- ret = -ENOMEM;
- goto err_init_60m_fclk;
- }
-
platform_set_drvdata(pdev, omap);
omap_usbhs_init(dev);
@@ -599,13 +588,10 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
goto err_alloc;
}
- goto end_probe;
+ return 0;
err_alloc:
omap_usbhs_deinit(&pdev->dev);
- iounmap(omap->uhh_base);
-
-err_init_60m_fclk:
clk_put(omap->init_60m_fclk);
err_usbhost_p2_fck:
@@ -629,9 +615,7 @@ err_utmi_p1_fck:
err_end:
clk_put(omap->ehci_logic_fck);
pm_runtime_disable(dev);
- kfree(omap);
-end_probe:
return ret;
}
@@ -646,7 +630,6 @@ static int __devexit usbhs_omap_remove(struct
platform_device *pdev)
struct usbhs_hcd_omap *omap = platform_get_drvdata(pdev);
omap_usbhs_deinit(&pdev->dev);
- iounmap(omap->uhh_base);
clk_put(omap->init_60m_fclk);
clk_put(omap->usbhost_p2_fck);
clk_put(omap->usbhost_p1_fck);
@@ -656,7 +639,6 @@ static int __devexit usbhs_omap_remove(struct
platform_device *pdev)
clk_put(omap->utmi_p1_fck);
clk_put(omap->ehci_logic_fck);
pm_runtime_disable(&pdev->dev);
- kfree(omap);
return 0;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 22/23] ARM: OMAP4: clock data: get rid of unused USB host clock aliases
We don't need multiple aliases for the OMAP USB host clocks so remove them.
CC: Paul Walmsley
CC: Rajendra Nayak
CC: Benoit Cousson
CC: Mike Turquette
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/cclock44xx_data.c |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index 74535fe..5a27244 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1858,7 +1858,6 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, "uart3_fck",&uart3_fck,
CK_443X),
CLK(NULL, "uart4_fck",&uart4_fck,
CK_443X),
CLK(NULL, "usb_host_fs_fck", &usb_host_fs_fck,
CK_443X),
- CLK("usbhs_omap", "fs_fck", &usb_host_fs_fck,
CK_443X),
CLK(NULL, "usb_host_hs_utmi_p1_clk",
&usb_host_hs_utmi_p1_clk, CK_443X),
CLK(NULL, "usb_host_hs_utmi_p2_clk",
&usb_host_hs_utmi_p2_clk, CK_443X),
CLK(NULL, "usb_host_hs_utmi_p3_clk",
&usb_host_hs_utmi_p3_clk, CK_443X),
@@ -1868,7 +1867,6 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, "usb_host_hs_hsic480m_p2_clk",
&usb_host_hs_hsic480m_p2_clk, CK_443X),
CLK(NULL, "usb_host_hs_func48mclk",
&usb_host_hs_func48mclk,CK_443X),
CLK(NULL, "usb_host_hs_fck", &usb_host_hs_fck,
CK_443X),
- CLK("usbhs_omap", "hs_fck", &usb_host_hs_fck,
CK_443X),
CLK(NULL, "otg_60m_gfclk",&otg_60m_gfclk,
CK_443X),
CLK(NULL, "usb_otg_hs_xclk", &usb_otg_hs_xclk,
CK_443X),
CLK(NULL, "usb_otg_hs_ick", &usb_otg_hs_ick,
CK_443X),
@@ -1878,8 +1876,6 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, "usb_tll_hs_usb_ch0_clk",
&usb_tll_hs_usb_ch0_clk,CK_443X),
CLK(NULL, "usb_tll_hs_usb_ch1_clk",
&usb_tll_hs_usb_ch1_clk,CK_443X),
CLK(NULL, "usb_tll_hs_ick", &usb_tll_hs_ick,
CK_443X),
- CLK("usbhs_omap", "usbtll_ick", &usb_tll_hs_ick,
CK_443X),
- CLK("usbhs_tll","usbtll_ick", &usb_tll_hs_ick,
CK_443X),
CLK(NULL, "usim_ck", &usim_ck,
CK_443X),
CLK(NULL, "usim_fclk",&usim_fclk,
CK_443X),
CLK(NULL, "usim_fck", &usim_fck,
CK_443X),
@@ -1930,9 +1926,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, "uart2_ick",&dummy_ck,
CK_443X),
CLK(NULL, "uart3_ick",&dummy_ck,
CK_443X),
CLK(NULL, "uart4_ick",&dummy_ck,
CK_443X),
- CLK("usbhs_omap", "usbhost_ick", &dummy_ck,
CK_443X),
- CLK("usbhs_omap", "usbtll_fck", &dummy_ck,
CK_443X),
- CLK("usbhs_tll","usbtll_fck", &dummy_ck,
CK_443X),
+ CLK(NULL, "usbhost_ick", &dummy_ck,
CK_443X),
CLK("omap_wdt", "ick", &dummy_ck,
CK_443X),
CLK(NULL, "timer_32k_ck", &sys_32k_ck,CK_443X),
/* TODO: Remove "omap_timer.X" aliases once DT migration is complete */
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 16/23] ARM: OMAP2+: clock data: Merge utmi_px_gfclk into usb_host_hs_utmi_px_clk
There is no such clock as utmi_p1_gfclk. It is only a clock selector
bit to select th the parent of usb_host_hs_utmi_p1_clk.
So we get rid of utmi_p1_gfclk and utmi_p2_gfclk by merging them into
usb_host_hs_utmi_p1_clk and usb_host_hs_utmi_p2_clk respectively.
CC: Paul Walmsley
CC: Rajendra Nayak
CC: Benoit Cousson
CC: Mike Turquette
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/cclock3xxx_data.c |2 -
arch/arm/mach-omap2/cclock44xx_data.c | 47 +++--
2 files changed, 33 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index bdf3948..5655414 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3392,8 +3392,6 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, "usbhost_48m_fck", &usbhost_48m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, "usbhost_ick", &usbhost_ick, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK("usbhs_omap", "usbhost_ick", &usbhost_ick, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
- CLK(NULL, "utmi_p1_gfclk",&dummy_ck, CK_3XXX),
- CLK(NULL, "utmi_p2_gfclk",&dummy_ck, CK_3XXX),
CLK(NULL, "xclk60mhsp1_ck", &dummy_ck, CK_3XXX),
CLK(NULL, "xclk60mhsp2_ck", &dummy_ck, CK_3XXX),
CLK(NULL, "usb_host_hs_utmi_p1_clk", &dummy_ck,
CK_3XXX),
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index aa56c3e..74535fe 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1366,31 +1366,52 @@ static struct clk_hw_omap usb_host_fs_fck_hw = {
DEFINE_STRUCT_CLK(usb_host_fs_fck, usb_host_fs_fck_parent_names,
usb_host_fs_fck_ops);
+static const struct clk_ops utmi_clk_ops = {
+ .enable = &omap2_dflt_clk_enable,
+ .disable= &omap2_dflt_clk_disable,
+ .is_enabled = &omap2_dflt_clk_is_enabled,
+ .recalc_rate= &omap2_clksel_recalc,
+ .get_parent = &omap2_clksel_find_parent_index,
+ .set_parent = &omap2_clksel_set_parent,
+};
+
static const char *utmi_p1_gfclk_parents[] = {
"init_60m_fclk", "xclk60mhsp1_ck",
};
-DEFINE_CLK_MUX(utmi_p1_gfclk, utmi_p1_gfclk_parents, NULL, 0x0,
- OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
- OMAP4430_CLKSEL_UTMI_P1_SHIFT, OMAP4430_CLKSEL_UTMI_P1_WIDTH,
- 0x0, NULL);
+static const struct clksel utmi_p1_clk_mux_sel[] = {
+ { .parent = &init_60m_fclk, .rates = div_1_0_rates },
+ { .parent = &xclk60mhsp1_ck, .rates = div_1_1_rates },
+ { .parent = NULL },
+};
-DEFINE_CLK_GATE(usb_host_hs_utmi_p1_clk, "utmi_p1_gfclk", &utmi_p1_gfclk, 0x0,
+/* Merged utmi_p1_gfclk into usb_host_hs_utmi_p1_clk */
+DEFINE_CLK_OMAP_MUX_GATE(usb_host_hs_utmi_p1_clk, "l3_init_clkdm",
+ utmi_p1_clk_mux_sel,
+ OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
+ OMAP4430_CLKSEL_UTMI_P1_MASK,
OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
- OMAP4430_OPTFCLKEN_UTMI_P1_CLK_SHIFT, 0x0, NULL);
+ OMAP4430_OPTFCLKEN_UTMI_P1_CLK_SHIFT, NULL,
+ utmi_p1_gfclk_parents, utmi_clk_ops);
static const char *utmi_p2_gfclk_parents[] = {
"init_60m_fclk", "xclk60mhsp2_ck",
};
-DEFINE_CLK_MUX(utmi_p2_gfclk, utmi_p2_gfclk_parents, NULL, 0x0,
- OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
- OMAP4430_CLKSEL_UTMI_P2_SHIFT, OMAP4430_CLKSEL_UTMI_P2_WIDTH,
- 0x0, NULL);
+static const struct clksel utmi_p2_clk_mux_sel[] = {
+ { .parent = &init_60m_fclk, .rates = div_1_0_rates },
+ { .parent = &xclk60mhsp2_ck, .rates = div_1_1_rates },
+ { .parent = NULL },
+};
-DEFINE_CLK_GATE(usb_host_hs_utmi_p2_clk, "utmi_p2_gfclk", &utmi_p2_gfclk, 0x0,
+/* Merged utmi_p2_gfclk into usb_host_hs_utmi_p2_clk */
+DEFINE_CLK_OMAP_MUX_GATE(usb_host_hs_utmi_p2_clk, "l3_init_clkdm",
+ utmi_p2_clk_mux_sel,
+ OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
+ OMAP4430_CLKSEL_UTMI_P2_MASK,
OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
- OMAP4430_OPTFCLKEN_UTMI_P2_CLK_SHIFT, 0x0, NULL);
+ OMAP4430_OPTFCLKEN_UTMI_P2_CLK_SHIFT, NULL,
+ utmi_p2_gfclk_parents, utmi_clk_ops);
DEFINE_CLK_GATE(usb_host_hs_utmi_p3_clk, "init_60m_fclk", &init_60m_fclk, 0x0,
OMAP4430_CM_L3INIT_USB_HOST_CLKCTRL,
@@ -1838,9 +1859,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, "uart4_fck",&uart4_fck,
CK_443X),
CLK(NULL, "usb_host_fs_fck", &usb_host_fs_fck,
CK_443X),
CLK("usbhs_omap", "fs_fck", &usb_host_fs_fck,
CK_443X),
- CLK(NULL, "utmi_p1_gfclk",
[PATCH v4 21/23] ARM: OMAP3: clock data: get rid of unused USB host clock aliases and dummies
We don't need multiple aliases for the OMAP USB host clocks and neither
the dummy clocks so remove them.
CC: Paul Walmsley
CC: Rajendra Nayak
CC: Benoit Cousson
CC: Mike Turquette
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/cclock3xxx_data.c | 11 ---
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 5655414..8b9d109 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3289,8 +3289,6 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, "cpefuse_fck", &cpefuse_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, "ts_fck", &ts_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, "usbtll_fck", &usbtll_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK("usbhs_omap", "usbtll_fck", &usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
- CLK("usbhs_tll","usbtll_fck", &usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(NULL, "core_96m_fck", &core_96m_fck, CK_3XXX),
CLK(NULL, "mmchs3_fck", &mmchs3_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, "mmchs2_fck", &mmchs2_fck,CK_3XXX),
@@ -3327,8 +3325,6 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, "pka_ick", &pka_ick, CK_34XX | CK_36XX),
CLK(NULL, "core_l4_ick", &core_l4_ick, CK_3XXX),
CLK(NULL, "usbtll_ick", &usbtll_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK("usbhs_omap", "usbtll_ick", &usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
- CLK("usbhs_tll","usbtll_ick", &usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK("omap_hsmmc.2", "ick", &mmchs3_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, "mmchs3_ick", &mmchs3_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, "icr_ick", &icr_ick, CK_34XX | CK_36XX),
@@ -3391,15 +3387,8 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, "usbhost_120m_fck", &usbhost_120m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, "usbhost_48m_fck", &usbhost_48m_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, "usbhost_ick", &usbhost_ick, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK("usbhs_omap", "usbhost_ick", &usbhost_ick, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(NULL, "xclk60mhsp1_ck", &dummy_ck, CK_3XXX),
CLK(NULL, "xclk60mhsp2_ck", &dummy_ck, CK_3XXX),
- CLK(NULL, "usb_host_hs_utmi_p1_clk", &dummy_ck,
CK_3XXX),
- CLK(NULL, "usb_host_hs_utmi_p2_clk", &dummy_ck,
CK_3XXX),
- CLK("usbhs_omap", "usb_tll_hs_usb_ch0_clk", &dummy_ck,
CK_3XXX),
- CLK("usbhs_omap", "usb_tll_hs_usb_ch1_clk", &dummy_ck,
CK_3XXX),
- CLK("usbhs_tll","usb_tll_hs_usb_ch0_clk", &dummy_ck,
CK_3XXX),
- CLK("usbhs_tll","usb_tll_hs_usb_ch1_clk", &dummy_ck,
CK_3XXX),
CLK(NULL, "init_60m_fclk",&dummy_ck, CK_3XXX),
CLK(NULL, "usim_fck", &usim_fck, CK_3430ES2PLUS |
CK_36XX),
CLK(NULL, "gpt1_fck", &gpt1_fck, CK_3XXX),
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 20/23] USB: ehci-omap: Don't free gpios that we didn't request
This driver does not request any gpios so don't free them.
Fixes L3 bus error on multiple modprobe/rmmod of ehci_hcd
with ehci-omap in use.
Signed-off-by: Roger Quadros
---
drivers/usb/host/ehci-omap.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 0d5ac36..9f7441b 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -291,7 +291,6 @@ static int ehci_hcd_omap_remove(struct platform_device
*pdev)
{
struct device *dev = &pdev->dev;
struct usb_hcd *hcd = dev_get_drvdata(dev);
- struct ehci_hcd_omap_platform_data *pdata = dev->platform_data;
usb_remove_hcd(hcd);
disable_put_regulator(dev->platform_data);
@@ -301,13 +300,6 @@ static int ehci_hcd_omap_remove(struct platform_device
*pdev)
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
- if (pdata->phy_reset) {
- if (gpio_is_valid(pdata->reset_gpio_port[0]))
- gpio_free(pdata->reset_gpio_port[0]);
-
- if (gpio_is_valid(pdata->reset_gpio_port[1]))
- gpio_free(pdata->reset_gpio_port[1]);
- }
return 0;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 18/23] mfd: omap-usb-host: Get rid of unnecessary spinlock
The driver does not have an interrupt handler and
we don't really need a spinlock, so get rid of it.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 90dbd17..289b356 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -23,7 +23,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -107,7 +106,6 @@ struct usbhs_hcd_omap {
struct usbhs_omap_platform_data *pdata;
u32 usbhs_rev;
- spinlock_t lock;
};
/*-*/
@@ -280,14 +278,12 @@ static bool is_ohci_port(enum usbhs_omap_port_mode pmode)
static int usbhs_runtime_resume(struct device *dev)
{
struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
- unsigned long flags;
struct usbhs_omap_platform_data *pdata = omap->pdata;
int i, r;
dev_dbg(dev, "usbhs_runtime_resume\n");
omap_tll_enable();
- spin_lock_irqsave(&omap->lock, flags);
if (omap->ehci_logic_fck && !IS_ERR(omap->ehci_logic_fck))
clk_enable(omap->ehci_logic_fck);
@@ -329,22 +325,17 @@ static int usbhs_runtime_resume(struct device *dev)
}
}
- spin_unlock_irqrestore(&omap->lock, flags);
-
return 0;
}
static int usbhs_runtime_suspend(struct device *dev)
{
struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
- unsigned long flags;
struct usbhs_omap_platform_data *pdata = omap->pdata;
int i;
dev_dbg(dev, "usbhs_runtime_suspend\n");
- spin_lock_irqsave(&omap->lock, flags);
-
for (i = 0; i < omap->nports; i++) {
switch (pdata->port_mode[i]) {
case OMAP_EHCI_PORT_MODE_HSIC:
@@ -367,7 +358,6 @@ static int usbhs_runtime_suspend(struct device *dev)
if (omap->ehci_logic_fck && !IS_ERR(omap->ehci_logic_fck))
clk_disable(omap->ehci_logic_fck);
- spin_unlock_irqrestore(&omap->lock, flags);
omap_tll_disable();
return 0;
@@ -377,7 +367,6 @@ static void omap_usbhs_init(struct device *dev)
{
struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
struct usbhs_omap_platform_data *pdata = omap->pdata;
- unsigned long flags;
unsignedreg;
dev_dbg(dev, "starting TI HSUSB Controller\n");
@@ -396,7 +385,6 @@ static void omap_usbhs_init(struct device *dev)
}
pm_runtime_get_sync(dev);
- spin_lock_irqsave(&omap->lock, flags);
reg = usbhs_read(omap->uhh_base, OMAP_UHH_HOSTCONFIG);
/* setup ULPI bypass and burst configurations */
@@ -459,8 +447,6 @@ static void omap_usbhs_init(struct device *dev)
usbhs_write(omap->uhh_base, OMAP_UHH_HOSTCONFIG, reg);
dev_dbg(dev, "UHH setup done, uhh_hostconfig=%x\n", reg);
- spin_unlock_irqrestore(&omap->lock, flags);
-
pm_runtime_put_sync(dev);
if (pdata->ehci_data->phy_reset) {
/* Hold the PHY in RESET for enough time till
@@ -524,8 +510,6 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
if (!omap->uhh_base)
return -EADDRNOTAVAIL;
- spin_lock_init(&omap->lock);
-
omap->pdata = pdata;
pm_runtime_enable(dev);
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 23/23] mfd: omap-usb-host: Don't spam console on clk_set_parent failure
clk_set_parent is expected to fail on OMAP3 platforms. We don't
consider that as fatal so don't spam console.
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 0bb54393..344ce09 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -657,32 +657,32 @@ static int __devinit usbhs_omap_probe(struct
platform_device *pdev)
}
if (is_ehci_phy_mode(pdata->port_mode[0])) {
- /* for OMAP3 , the clk set paretn fails */
+ /* for OMAP3, clk_set_parent fails */
ret = clk_set_parent(omap->utmi_clk[0],
omap->xclk60mhsp1_ck);
if (ret != 0)
- dev_err(dev, "xclk60mhsp1_ck set parent"
- "failed error:%d\n", ret);
+ dev_dbg(dev, "xclk60mhsp1_ck set parent failed: %d\n",
+ ret);
} else if (is_ehci_tll_mode(pdata->port_mode[0])) {
ret = clk_set_parent(omap->utmi_clk[0],
omap->init_60m_fclk);
if (ret != 0)
- dev_err(dev, "init_60m_fclk set parent"
- "failed error:%d\n", ret);
+ dev_dbg(dev, "P0 init_60m_fclk set parent failed: %d\n",
+ ret);
}
if (is_ehci_phy_mode(pdata->port_mode[1])) {
ret = clk_set_parent(omap->utmi_clk[1],
omap->xclk60mhsp2_ck);
if (ret != 0)
- dev_err(dev, "xclk60mhsp2_ck set parent"
- "failed error:%d\n", ret);
+ dev_dbg(dev, "xclk60mhsp2_ck set parent failed: %d\n",
+ ret);
} else if (is_ehci_tll_mode(pdata->port_mode[1])) {
ret = clk_set_parent(omap->utmi_clk[1],
omap->init_60m_fclk);
if (ret != 0)
- dev_err(dev, "init_60m_fclk set parent"
- "failed error:%d\n", ret);
+ dev_dbg(dev, "P1 init_60m_fclk set parent failed: %d\n",
+ ret);
}
omap_usbhs_init(dev);
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] OMAPFB: connect ovl managers to all dssdevs
On 2012-12-10 11:54, Archit Taneja wrote: > On Monday 10 December 2012 01:33 PM, Tomi Valkeinen wrote: >> Another option would be to pass information about mgr-output links from >> the board files (or DT data) to the omapdss driver, so that omapdss >> could setup them at probe time. With this option omapfb/omapdrm doesn't >> need to care about this, and it doesn't create load order restriction. >> But mgr-output links are something that I'd really like to handle inside >> the drivers, not something that needs to be passed via platform data. > > This would definitely make things simpler, but if this parameter is put > in a panel's DT, it would become omap specific. We could add this info > to the DT corresponding to omapdss. Yes, I meant it should be omapdss platform data. Nothing related to panels. >> Third option, which is the best, but also something I have no idea how >> to implement, would be to create the mgr-output links dynamically when >> needed. The problem here is, of course, that a mgr could be allocated to >> an output, only to be later found out that that particular mgr is needed >> for another output. >> >> But this is something we could study a bit: can we create such mgr >> allocation system, that no matter what outputs the board uses, it'll >> just work. > > Yes, that would be quite useful. But I think we'll hit situations where > it is sort of impossible to prevent the above situation. > > When an output needs a manager. We could study the current state of the > system by splitting managers into 2 sets: > > A: managers which already have outputs connected to them > B: managers which don't have an output, but might get connected to one > in the future. > > managers in A are lost, and we can't detach them, we would need to at > least disable/reenable the panel with a new manager connected to the > output. > > we need to find one from B such that maximum outputs(or some other > weightage factor) will still be supported after this new link is made. > > The system will initially have all managers in B, but eventually > managers will move to A. We need to move one manager from B to A for > every mgr-output link. > > I guess I just described the problem in a more mathematical way, without > providing any solution :), but it does look like an optimisation problem. Well, optimization problem sounds like something that can always be solved. But in this case the driver may need to predict what outputs will be used, which is of course impossible. >> So, for example, on omap4, LCD2 mgr can be used for DPI, DSI2, DSI1, and >> RFBI. LCD1 can be used for RFBI and DSI1. If we know that DSI1 and RFBI >> cannot be used at the same time, we're free to give LCD1 to either one. > > But they can be used together, can't they? LCD1->DSI1 and LCD2->RFBI. > Are you creating this constraint by assuming what the board is like? Or > is this a constraint of OMAP DSS HW? I didn't check if they can be used together or not, I was just guessing. At least on OMAP3 DSI and RFBI shared the same pins, so they could not be used at the same time. Perhaps we should implement a mixed approach: the driver presumes certain things, like "if DSI is used, RFBI is not used", based on the knowledge of what kind of boards there currently are. This would allow us to manage the mgr->output connections in the driver for, say, 95% of the cases. Then we'd also have the platform data parameters for omapdss, which could be used in the weird cases. >> And if we know that DPI and DSI2 cannot be used at the same time, we're >> also free to give LCD2 to either one. And if that's the case, there are >> no conflicts. > > This is also possible at the same time: TV->DPI and LCD2->DSI2 True. I was just again guessing. On OMAP3 DPI and DSI shared the same pins. Thinking about this, OMAP4 does have separate pins for DSI, doesn't it? So my guesses don't hold. >> I don't know if we can find such allocation for all current omaps, and I >> know it's slightly risky as the next omap could have limitations even if >> current ones do not. > > I don't understand the example so well, but I get your point of taking > advantage of such limitations. > >> >>> Also, we would need to do this for omapdrm separately using it's own >>> encoder/connector entities. >> >> Yep. That's also a negative side: both omapfb/omapdrm will need to >> implement the same stuff, even if neither of them are really interested >> in that stuff. > > Yes. I wonder if crtcs, encoders and connectors already have some sort > of helpers for this? Probably nothing that helps us, as this is OMAP HW restriction. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 5/5] OMAPFB: connect ovl managers to all dssdevs
On Monday 10 December 2012 01:33 PM, Tomi Valkeinen wrote:
On 2012-12-10 09:34, Archit Taneja wrote:
Hi,
On Friday 07 December 2012 05:25 PM, Tomi Valkeinen wrote:
Commit 5d89bcc341771d95e3a2996218e5949a6627f59e (OMAPDSS: remove initial
display code from omapdss) moved setting up the initial overlay, overlay
manager, output and display connections from omapdss to omapfb.
However, currently omapfb only handles the connection related to the
default display, which means that no overlay managers are connected to
other displays.
This patch changes omapfb to go through all dssdevs, and connect an
overlay manager to them.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/omapfb/omapfb-main.c | 38
+++---
1 file changed, 24 insertions(+), 14 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 1df973e..24739fc 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2353,27 +2353,37 @@ static int omapfb_init_display(struct
omapfb2_device *fbdev,
}
static int omapfb_init_connections(struct omapfb2_device *fbdev,
-struct omap_dss_device *dssdev)
+struct omap_dss_device *def_dssdev)
{
int i, r;
-struct omap_overlay_manager *mgr = NULL;
+struct omap_overlay_manager *mgr;
-for (i = 0; i < fbdev->num_managers; i++) {
-mgr = fbdev->managers[i];
-
-if (dssdev->channel == mgr->id)
-break;
+if (!def_dssdev->output) {
+dev_err(fbdev->dev, "no output for the default display\n");
+return -EINVAL;
}
-if (i == fbdev->num_managers)
-return -ENODEV;
+for (i = 0; i < fbdev->num_displays; ++i) {
+struct omap_dss_device *dssdev = fbdev->displays[i].dssdev;
+struct omap_dss_output *out = dssdev->output;
-if (mgr->output)
-mgr->unset_output(mgr);
+mgr = omap_dss_get_overlay_manager(dssdev->channel);
This dssdev->channel reference is something we would want to get rid of
eventually, right?
Yes.
At the point omapfb_init_connections() is called, we would have all the
omap_dss_devices registered, right? So at this point, omapfb will have
an overall view of how the panels need to be connected to DSS.
I think we can try to find a manager here for dssdev rather than using
dssdev->channel directly. The dssdev's output could connect to a few
managers. We would want to chose managers for each dssdev output in such
a way that all outputs have a manager. I guess there would be multiple
combinations for this, but it would be okay to pick any one of them.
I think we would need some recursive or backtracking sort of approach to
get a desired combination. We can figure about how to make it work
later, but do you agree if this is a right way to get rid of
dssdev->channel?
Yes, I think that's a sensible approach. The thing I don't like about it
is that it requires omapfb/omapdrm to create the mgr-output connections.
They shouldn't really be interested in that. All they want is a display
device that works, and a way to get the mgr used for the display.
Well, I think we can hide the implementation inside omapdss, so that
omapfb/omapdrm will just need to call one omapdss func when they are
started, which will connect the mgrs to outputs.
A downside with setting up the mgr-output links at one go, when
omapfb/omapdrm starts, is that it creates a strict load order
restriction between omapdss, panels and omapfb/omapdrm. The drivers will
need to be loaded in that order, or things won't work.
Yes, that's true.
Another option would be to pass information about mgr-output links from
the board files (or DT data) to the omapdss driver, so that omapdss
could setup them at probe time. With this option omapfb/omapdrm doesn't
need to care about this, and it doesn't create load order restriction.
But mgr-output links are something that I'd really like to handle inside
the drivers, not something that needs to be passed via platform data.
This would definitely make things simpler, but if this parameter is put
in a panel's DT, it would become omap specific. We could add this info
to the DT corresponding to omapdss.
Third option, which is the best, but also something I have no idea how
to implement, would be to create the mgr-output links dynamically when
needed. The problem here is, of course, that a mgr could be allocated to
an output, only to be later found out that that particular mgr is needed
for another output.
But this is something we could study a bit: can we create such mgr
allocation system, that no matter what outputs the board uses, it'll
just work.
Yes, that would be quite useful. But I think we'll hit situations where
it is sort of impossible to prevent the above situation.
When an output needs a manager. We could study the current state of the
system by splitting managers into 2 sets:
A: managers which already have outpu
Re: [RFC PATCH 1/5] drivers : introduce device_path api
On 12/06/2012 04:34 PM, Jassi Brar wrote: > On Wed, Dec 5, 2012 at 7:39 PM, Roger Quadros wrote: >> Hi Jassi, >> >> On 12/01/2012 09:49 AM, Jassi Brar wrote: >>> On Tue, Nov 27, 2012 at 10:32 PM, Greg KH >>> wrote: On Tue, Nov 27, 2012 at 11:30:11AM -0500, Alan Stern wrote: > > We should have a more generic solution in a more central location, like > the device core. > > For example, each struct platform_device could have a list of resources > to be enabled when the device is bound to a driver and disabled when > the device is unbound. Such a list could include regulators, clocks, > and whatever else people can invent. > > In this case, when it is created the ehci-omap.0 platform device could > get an entry pointing to the LAN95xx's regulator. Then the regulator > would automatically be turned on when the platform device is bound to > the ehci-omap driver. > > How does this sound? That sounds much better, and it might come in handy for other types of devices than platform devices, so feel free to put this on the core 'struct device' instead if needed. >>> Isn't enabling/disabling of clocks and regulators what >>> dev.probe()/remove() of any driver already does? >>> If we mean only board specific setup/teardown, still it would mean >>> having the device core to do an extra 'probe' call when the current >>> probe() is already meant to do whatever it takes to bring the device >>> up. To my untrained eyes, it seem like messing with the >>> probe()/remove()'s semantics. >>> IMHO, if we really must implement something like that, may be we >>> should employ some 'broadcast mechanism' so that anything anywhere in >>> kernel knows which new device has been probed()/removed() >>> successfully. I haven't thought exactly how because I am not sure even >>> that would be the right way to approach PandaBoard's problem. >>> >>> Looking at "Figure 15 – Panda USBB1 Interface Block Diagram" of >>> http://pandaboard.org/sites/default/files/board_reference/pandaboard-es-b/panda-es-b-manual.pdf >>> gives me visions ... >>> >>> 1) OMAP doesn't provide the USB root-hub, but only ULPIPHY. It is >>> USB3320C chip that employs OMAP's ULPIPHY to provide the root-hub. So >>> we should have a platform device for USB3320C, the probe() of which >>> should simply >> >> Actually the EHCI controller within OMAP provides the root hub with 3 >> ports but no PHY. One of them is connected to the USB3320 which is just >> a ULPI PHY. >> >>>a) Enable REFCLK (FREF_CLK3_OUT) >>>b) Reset itself by cycling RESETB (GPIO_62) >>>c) Create one "ehci-omap" platform device >> >> c) is not appropriate. ehci-omap must be created before usb3320. >> >>> (or in appropriate order if the above isn't) >>> That way insmod/rmmod'ing the USB3320C driver would power-up/down the >>> whole subsystem. >> >> Yes, this is where we can think of a generic PHY driver to make sure thy >> PHY has necessary resources enabled. In the Panda case it would be the >> PHY clock and RESET gpio. >> > I wonder if ehci-omap should assume, besides regulator, a clock might > also be need to setup for the transceiver chip. > Maybe "usbhs_bdata" in board-omap4panda.c should have > .reset_gpio_port[0] = GPIO_HUB_NRESET ? > Just like the regulator, reset_gpio_port has nothing to do with OMAP EHCI. So we would want to get rid of that too from the OMAP USB driver. > >> The LAN95xx chip still needs to be powered up and the PHY driver isn't >> the right place for that (though it could be done there as a hack). The >> closest we can get to emulating right USB behavior is to map the >> SET/CLEAR PORT_FEATURE of the root hub port to the regulator that powers >> the LAN95xx. >> >> This way, we still don't fall in the dynamically probed space, so we >> could still provide the regulator information to the ehci hub via >> platform data and handle the regulator in ehci_hub_control >> (Set/ClearPortFeature). I'm looking at this as a software workaround for >> all platforms not implementing the EHCI set port power feature >> correctly. The same could be repeated for other HCDs as well if required. >> > IMHO it's not a matter of platforms not implementing EHCI set port > power feature correctly, we should think about onboard devices > connected to onboard non-root hubs. Setups like LAN9514 on Panda (HSIC > too ?) that don't run on VBUS of USB, would like their local supply to > be treated as if it came from the parent hub's port i.e, tie together > the USB's set port power control with their OOB regulated power supply > (U9 on PandaBoard). > On Pandaboards we are still talking about root hub ports. Do you know any of such platforms which power their USB devices out of band for _non_ root hub ports? Assuming they do exist, the only solution is to match platform data for dynamically probed devices and deal with the regulators in the hub/port driver. Something like Andy already proposed. regard
Re: [PATCH v3 01/23] mfd: omap-usb-host: get rid of cpu_is_omap..() macros
On 12/05/2012 08:42 PM, Tony Lindgren wrote: > * Roger Quadros [121204 06:15]: >> Instead of using cpu_is_omap..() macros in the device driver we >> rely on information provided in the platform data. >> >> The only information we need is whether the USB Host module has >> a single ULPI bypass control bit for all ports or individual bypass >> control bits for each port. OMAP3 REV2.1 and earlier have the former. > > Thanks for moving this one earlier in the series. Looks like > you're missing Samuel as the MFD maintainer from your cc. > You should resend again with Samuel Ortiz > added. > > Maybe check the patches in this series with scripts/get_maintainer.pl > to see who all should be cc:ed? > OK, I'll resend this series with appropriate maintainers in cc. regards, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] da8xx: Allow use by am33xx based devices
On 12/6/2012 1:38 PM, Manjunathappa, Prakash wrote: > Hi Tomi, > > On Wed, Oct 31, 2012 at 10:52:59, Manjunathappa, Prakash wrote: >> Hi, >> >> On Wed, Oct 31, 2012 at 21:26:08, Pantelis Antoniou wrote: >>> This driver can be used for AM33xx devices, like the popular beaglebone. >>> >>> Signed-off-by: Pantelis Antoniou >>> --- >>> drivers/video/Kconfig | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig >>> index 9791d10..e7868d8 100644 >>> --- a/drivers/video/Kconfig >>> +++ b/drivers/video/Kconfig >>> @@ -2202,7 +2202,7 @@ config FB_SH7760 >>> >>> config FB_DA8XX >>> tristate "DA8xx/OMAP-L1xx Framebuffer support" >>> - depends on FB && ARCH_DAVINCI_DA8XX >>> + depends on FB && (ARCH_DAVINCI_DA8XX || SOC_AM33XX) >> >> Agreed this is present on da8xx and am33xx, but moving forward for >> supporting DT, we should be avoiding these dependencies. So instead >> change this to remove machine dependencies. >> > > I could be wrong here, having dependency on platform seems to be right. > Otherwise may lead to build errors for other platforms. No, it should not result in to build error unless driver uses some platform specific api's. Thanks, Vaibhav > Please ignore my > comments and accept this patch. > > Thanks, > Prakash > ___ > Davinci-linux-open-source mailing list > davinci-linux-open-sou...@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] net: ethernet: davinci_cpdma: Add boundary for rx and tx descriptors
Hi again, On Mon, Dec 10, 2012 at 8:37 AM, Mugunthan V N wrote: > When there is heavy transmission traffic in the CPDMA, then Rx descriptors > memory is also utilized as tx desc memory this leads to reduced rx desc memory > which leads to poor performance. > "poor performance" is an understatement, see Sascha's description of his patch. At initialization of the driver, half of the descriptors in the pool are allocated for rx. When a packet arrives, one of the rx descriptors is released and a new one is allocated. If tx allocates this descriptor in the meantime, it is lost for rx forever! If tx consumes all rx descriptors this way, the rx channel is dead! Regards, Christian > This patch adds boundary for tx and rx descriptors in bd ram dividing the > descriptor memory to ensure that during heavy transmission tx doesn't use > rx descriptors. > > This patch is already applied to davinci_emac driver, since CPSW and > davici_dmac uses the same CPDMA, moving the boundry seperation from > Davinci EMAC driver to CPDMA driver which was done in the following > commit > > commit 86d8c07ff2448eb4e860e50f34ef6ee78e45c40c > Author: Sascha Hauer > Date: Tue Jan 3 05:27:47 2012 + > > net/davinci: do not use all descriptors for tx packets > > The driver uses a shared pool for both rx and tx descriptors. > During open it queues fixed number of 128 descriptors for receive > packets. For each received packet it tries to queue another > descriptor. If this fails the descriptor is lost for rx. > The driver has no limitation on tx descriptors to use, so it > can happen during a nmap / ping -f attack that the driver > allocates all descriptors for tx and looses all rx descriptors. > The driver stops working then. > To fix this limit the number of tx descriptors used to half of > the descriptors available, the rx path uses the other half. > > Tested on a custom board using nmap / ping -f to the board from > two different hosts. > > Signed-off-by: Mugunthan V N -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] net: ethernet: davinci_cpdma: Add boundary for rx and tx descriptors
Hi,
On Mon, Dec 10, 2012 at 8:37 AM, Mugunthan V N wrote:
> When there is heavy transmission traffic in the CPDMA, then Rx descriptors
> memory is also utilized as tx desc memory this leads to reduced rx desc memory
> which leads to poor performance.
>
> This patch adds boundary for tx and rx descriptors in bd ram dividing the
> descriptor memory to ensure that during heavy transmission tx doesn't use
> rx descriptors.
>
> This patch is already applied to davinci_emac driver, since CPSW and
> davici_dmac uses the same CPDMA, moving the boundry seperation from
> Davinci EMAC driver to CPDMA driver which was done in the following
> commit
>
> commit 86d8c07ff2448eb4e860e50f34ef6ee78e45c40c
> Author: Sascha Hauer
> Date: Tue Jan 3 05:27:47 2012 +
>
> net/davinci: do not use all descriptors for tx packets
>
> The driver uses a shared pool for both rx and tx descriptors.
> During open it queues fixed number of 128 descriptors for receive
> packets. For each received packet it tries to queue another
> descriptor. If this fails the descriptor is lost for rx.
> The driver has no limitation on tx descriptors to use, so it
> can happen during a nmap / ping -f attack that the driver
> allocates all descriptors for tx and looses all rx descriptors.
> The driver stops working then.
> To fix this limit the number of tx descriptors used to half of
> the descriptors available, the rx path uses the other half.
>
> Tested on a custom board using nmap / ping -f to the board from
> two different hosts.
>
> Signed-off-by: Mugunthan V N
> ---
> drivers/net/ethernet/ti/davinci_cpdma.c | 20 ++--
> drivers/net/ethernet/ti/davinci_emac.c |8
> 2 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c
> b/drivers/net/ethernet/ti/davinci_cpdma.c
> index 4995673..d37f546 100644
> --- a/drivers/net/ethernet/ti/davinci_cpdma.c
> +++ b/drivers/net/ethernet/ti/davinci_cpdma.c
> @@ -105,13 +105,13 @@ struct cpdma_ctlr {
> };
>
> struct cpdma_chan {
> + struct cpdma_desc __iomem *head, *tail;
> + void __iomem*hdp, *cp, *rxfree;
> enum cpdma_statestate;
> struct cpdma_ctlr *ctlr;
> int chan_num;
> spinlock_t lock;
> - struct cpdma_desc __iomem *head, *tail;
> int count;
> - void __iomem*hdp, *cp, *rxfree;
Why?
> u32 mask;
> cpdma_handler_fnhandler;
> enum dma_data_direction dir;
> @@ -217,7 +217,7 @@ desc_from_phys(struct cpdma_desc_pool *pool, dma_addr_t
> dma)
> }
>
> static struct cpdma_desc __iomem *
> -cpdma_desc_alloc(struct cpdma_desc_pool *pool, int num_desc)
> +cpdma_desc_alloc(struct cpdma_desc_pool *pool, int num_desc, bool is_rx)
> {
> unsigned long flags;
> int index;
> @@ -225,8 +225,14 @@ cpdma_desc_alloc(struct cpdma_desc_pool *pool, int
> num_desc)
>
> spin_lock_irqsave(&pool->lock, flags);
>
> - index = bitmap_find_next_zero_area(pool->bitmap, pool->num_desc, 0,
> - num_desc, 0);
> + if (is_rx) {
> + index = bitmap_find_next_zero_area(pool->bitmap,
> + pool->num_desc/2, 0, num_desc, 0);
> +} else {
> + index = bitmap_find_next_zero_area(pool->bitmap,
> + pool->num_desc, pool->num_desc/2, num_desc,
> 0);
> + }
Would it make sense to use two separate pools for rx and tx instead,
struct cpdma_desc_pool *rxpool, *txpool? It would result in using
separate spinlocks for rx and tx, could this be an advantage? (I am a
newbie in this field...)
> +
> if (index < pool->num_desc) {
> bitmap_set(pool->bitmap, index, num_desc);
> desc = pool->iomap + pool->desc_size * index;
> @@ -660,6 +666,7 @@ int cpdma_chan_submit(struct cpdma_chan *chan, void
> *token, void *data,
> unsigned long flags;
> u32 mode;
> int ret = 0;
> + boolis_rx;
>
> spin_lock_irqsave(&chan->lock, flags);
>
> @@ -668,7 +675,8 @@ int cpdma_chan_submit(struct cpdma_chan *chan, void
> *token, void *data,
> goto unlock_ret;
> }
>
> - desc = cpdma_desc_alloc(ctlr->pool, 1);
> + is_rx = (chan->rxfree != 0);
> + desc = cpdma_desc_alloc(ctlr->pool, 1, is_rx);
> if (!desc) {
> chan->stats.desc_alloc_fail++;
> ret = -ENOMEM;
> diff --git a/drivers/net/ethernet/ti/davinci_emac.c
> b/drivers/net/ethernet/ti/davinci_emac.c
> index fce89a0..f349273 100644
> --- a/drivers/net/ethernet/ti/davinci_em
Re: [PATCH 5/5] OMAPFB: connect ovl managers to all dssdevs
On 2012-12-10 09:34, Archit Taneja wrote:
> Hi,
>
> On Friday 07 December 2012 05:25 PM, Tomi Valkeinen wrote:
>> Commit 5d89bcc341771d95e3a2996218e5949a6627f59e (OMAPDSS: remove initial
>> display code from omapdss) moved setting up the initial overlay, overlay
>> manager, output and display connections from omapdss to omapfb.
>>
>> However, currently omapfb only handles the connection related to the
>> default display, which means that no overlay managers are connected to
>> other displays.
>>
>> This patch changes omapfb to go through all dssdevs, and connect an
>> overlay manager to them.
>>
>> Signed-off-by: Tomi Valkeinen
>> ---
>> drivers/video/omap2/omapfb/omapfb-main.c | 38
>> +++---
>> 1 file changed, 24 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
>> b/drivers/video/omap2/omapfb/omapfb-main.c
>> index 1df973e..24739fc 100644
>> --- a/drivers/video/omap2/omapfb/omapfb-main.c
>> +++ b/drivers/video/omap2/omapfb/omapfb-main.c
>> @@ -2353,27 +2353,37 @@ static int omapfb_init_display(struct
>> omapfb2_device *fbdev,
>> }
>>
>> static int omapfb_init_connections(struct omapfb2_device *fbdev,
>> -struct omap_dss_device *dssdev)
>> +struct omap_dss_device *def_dssdev)
>> {
>> int i, r;
>> -struct omap_overlay_manager *mgr = NULL;
>> +struct omap_overlay_manager *mgr;
>>
>> -for (i = 0; i < fbdev->num_managers; i++) {
>> -mgr = fbdev->managers[i];
>> -
>> -if (dssdev->channel == mgr->id)
>> -break;
>> +if (!def_dssdev->output) {
>> +dev_err(fbdev->dev, "no output for the default display\n");
>> +return -EINVAL;
>> }
>>
>> -if (i == fbdev->num_managers)
>> -return -ENODEV;
>> +for (i = 0; i < fbdev->num_displays; ++i) {
>> +struct omap_dss_device *dssdev = fbdev->displays[i].dssdev;
>> +struct omap_dss_output *out = dssdev->output;
>>
>> -if (mgr->output)
>> -mgr->unset_output(mgr);
>> +mgr = omap_dss_get_overlay_manager(dssdev->channel);
>
> This dssdev->channel reference is something we would want to get rid of
> eventually, right?
Yes.
> At the point omapfb_init_connections() is called, we would have all the
> omap_dss_devices registered, right? So at this point, omapfb will have
> an overall view of how the panels need to be connected to DSS.
>
> I think we can try to find a manager here for dssdev rather than using
> dssdev->channel directly. The dssdev's output could connect to a few
> managers. We would want to chose managers for each dssdev output in such
> a way that all outputs have a manager. I guess there would be multiple
> combinations for this, but it would be okay to pick any one of them.
>
> I think we would need some recursive or backtracking sort of approach to
> get a desired combination. We can figure about how to make it work
> later, but do you agree if this is a right way to get rid of
> dssdev->channel?
Yes, I think that's a sensible approach. The thing I don't like about it
is that it requires omapfb/omapdrm to create the mgr-output connections.
They shouldn't really be interested in that. All they want is a display
device that works, and a way to get the mgr used for the display.
Well, I think we can hide the implementation inside omapdss, so that
omapfb/omapdrm will just need to call one omapdss func when they are
started, which will connect the mgrs to outputs.
A downside with setting up the mgr-output links at one go, when
omapfb/omapdrm starts, is that it creates a strict load order
restriction between omapdss, panels and omapfb/omapdrm. The drivers will
need to be loaded in that order, or things won't work.
Another option would be to pass information about mgr-output links from
the board files (or DT data) to the omapdss driver, so that omapdss
could setup them at probe time. With this option omapfb/omapdrm doesn't
need to care about this, and it doesn't create load order restriction.
But mgr-output links are something that I'd really like to handle inside
the drivers, not something that needs to be passed via platform data.
Third option, which is the best, but also something I have no idea how
to implement, would be to create the mgr-output links dynamically when
needed. The problem here is, of course, that a mgr could be allocated to
an output, only to be later found out that that particular mgr is needed
for another output.
But this is something we could study a bit: can we create such mgr
allocation system, that no matter what outputs the board uses, it'll
just work.
So, for example, on omap4, LCD2 mgr can be used for DPI, DSI2, DSI1, and
RFBI. LCD1 can be used for RFBI and DSI1. If we know that DSI1 and RFBI
cannot be used at the same time, we're free to give LCD1 to either one.
And if we know that DPI and DSI2 cannot be used at the same time, we're
also free to give LCD2 to either one. And if that's the case, there are
no conflicts.
I
