Re: Powering OMAP's pins
On Wed, 2012-09-26 at 11:59 -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [120926 00:06]: So if I want to use parallel dss output, which uses dss_data0 pin, omapdss driver needs to enable vdda_dsi on omap3430, even though there's no other use for vdda_dsi in the parallel output case. But on omap4430 data0 pins seems to be powered by vdds_1p8v. On AM35xx something else. So either I need to program all those into the omapdss driver, which is not the right way as they are platform specific things, or I need to pass some kind of pin data from platform data to omapdss driver, giving the required regulator for each pin. Pass the device tree regulators to the DSS driver and enable the ones with runtime PM in the DSS driver? I guess you have the names for those regulatros? Well, yes, I could create a pin-regulator mapping for dss that is filled in the DT data. I just feel this is something that the omapdss driver shouldn't care about. The powers for the pins are in no way related to dss. And how about the uart1_cts or gpio_70 pins on 3430? Do both uart and gpio drivers need to have similar kind of platform data, giving the required regulator so that the pin can be enabled? Hmm aren't those always enabled with VIO_18? No, 3430 datamanual (OMAP34xx_ES2.0_ES2.1_POP_DM_V_K.pdf) says some uart and gpio pins are powered by vdds_dsi, some by vdds_sdi, some gpio pins are powered by vdds_csi2, etc. I could be mistaken how to HW works (but it does work like that for dss), but sounds to me that uart and gpio drivers (and perhaps some others, I didn't go through all the pins) need similar pin-regulator mapping as you suggested for omapdss. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 1/2] omap3: Provide means for changing CSI2 PHY configuration
Hi Sakari,
Thanks for the patch.
On Thursday 27 September 2012 00:50:35 Sakari Ailus wrote:
The OMAP 3630 has configuration how the ISP CSI-2 PHY pins are connected to
the actual CSI-2 receivers outside the ISP itself. Allow changing this
configuration from the ISP driver.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Just one small comment below, otherwise
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/arm/mach-omap2/control.c | 86 +
arch/arm/mach-omap2/control.h | 15 +
arch/arm/mach-omap2/include/mach/control.h | 13
3 files changed, 114 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/include/mach/control.h
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 3223b81..11bb900 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -12,9 +12,12 @@
*/
#undef DEBUG
+#include linux/export.h
#include linux/kernel.h
#include linux/io.h
+#include mach/control.h
+
#include plat/hardware.h
#include plat/sdrc.h
@@ -607,4 +610,87 @@ int omap3_ctrl_save_padconf(void)
return 0;
}
+static int omap3630_ctrl_csi2_phy_cfg(u32 phy, u32 flags)
+{
+ u32 cam_phy_ctrl =
+ omap_ctrl_readl(OMAP3630_CONTROL_CAMERA_PHY_CTRL);
+ u32 shift, mode;
+
+ switch (phy) {
+ case OMAP3_CTRL_CSI2_PHY1_CCP2B:
+ cam_phy_ctrl =
~OMAP3630_CONTROL_CAMERA_PHY_CTRL_CSI1_RX_SEL_PHY2;
+ shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY1_SHIFT;
+ break;
+ case OMAP3_CTRL_CSI2_PHY1_CSI2C:
+ shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY1_SHIFT;
+ mode = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_DPHY;
+ break;
+ case OMAP3_CTRL_CSI2_PHY2_CCP2B:
+ cam_phy_ctrl |=
OMAP3630_CONTROL_CAMERA_PHY_CTRL_CSI1_RX_SEL_PHY2;
+ shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY2_SHIFT;
+ break;
+ case OMAP3_CTRL_CSI2_PHY2_CSI2A:
+ shift = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_PHY2_SHIFT;
+ mode = OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_DPHY;
+ break;
+ default:
+ pr_warn(bad phy %d\n, phy);
+ return -EINVAL;
+ }
+
+ /* Select data/clock or data/strobe mode for CCP2 */
+ switch (phy) {
+ case OMAP3_CTRL_CSI2_PHY1_CCP2B:
+ case OMAP3_CTRL_CSI2_PHY2_CCP2B:
+ if (flags OMAP3_CTRL_CSI2_CFG_CCP2_DATA_STROBE)
+ mode =
OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_CCP2_DATA_STROBE;
+ else
+ mode =
OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_CCP2_DATA_CLOCK;
+ break;
+ }
+
+ cam_phy_ctrl = ~(OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_MASK
shift);
+ cam_phy_ctrl |= mode shift;
+
+ omap_ctrl_writel(cam_phy_ctrl,
+ OMAP3630_CONTROL_CAMERA_PHY_CTRL);
This can fit on one line.
+
+ return 0;
+}
+
+static int omap3430_ctrl_csi2_phy_cfg(u32 phy, bool on, u32 flags)
+{
+ uint32_t csirxfe = OMAP343X_CONTROL_CSIRXFE_PWRDNZ
+ | OMAP343X_CONTROL_CSIRXFE_RESET;
+
+ /* Nothing to configure here. */
+ if (phy == OMAP3_CTRL_CSI2_PHY2_CSI2A)
+ return 0;
+
+ if (phy != OMAP3_CTRL_CSI2_PHY1_CCP2B)
+ return -EINVAL;
+
+ if (!on) {
+ omap_ctrl_writel(0, OMAP343X_CONTROL_CSIRXFE);
+ return 0;
+ }
+
+ if (flags OMAP3_CTRL_CSI2_CFG_CCP2_DATA_STROBE)
+ csirxfe |= OMAP343X_CONTROL_CSIRXFE_SELFORM;
+
+ omap_ctrl_writel(csirxfe, OMAP343X_CONTROL_CSIRXFE);
+
+ return 0;
+}
+
+int omap3_ctrl_csi2_phy_cfg(u32 phy, bool on, u32 flags)
+{
+ if (cpu_is_omap3630() on)
+ return omap3630_ctrl_csi2_phy_cfg(phy, flags);
+ if (cpu_is_omap3430())
+ return omap3430_ctrl_csi2_phy_cfg(phy, on, flags);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(omap3_ctrl_csi2_phy_cfg);
+
#endif /* CONFIG_ARCH_OMAP3 CONFIG_PM */
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index b8cdc85..7b2ee5d 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -132,6 +132,11 @@
#define OMAP343X_CONTROL_MEM_DFTRW1 (OMAP2_CONTROL_GENERAL + 0x000c)
#define OMAP343X_CONTROL_DEVCONF1(OMAP2_CONTROL_GENERAL + 0x0068)
#define OMAP343X_CONTROL_CSIRXFE (OMAP2_CONTROL_GENERAL + 0x006c)
+#define OMAP343X_CONTROL_CSIRXFE_CSIB_INV(1 7)
+#define OMAP343X_CONTROL_CSIRXFE_RESENABLE (1 8)
+#define OMAP343X_CONTROL_CSIRXFE_SELFORM (1 10)
+#define OMAP343X_CONTROL_CSIRXFE_PWRDNZ (1 12)
+#define OMAP343X_CONTROL_CSIRXFE_RESET (1 13)
#define OMAP343X_CONTROL_SEC_STATUS (OMAP2_CONTROL_GENERAL + 0x0070)
#define
Re: [RFC PATCH 10/13] spi: omap2-mcspi: dma_request_slave_channel() support for DT platforms
On Fri, 2012-09-21 at 14:37 -0400, Matt Porter wrote: On Fri, Sep 21, 2012 at 08:42:47AM -0700, Tony Lindgren wrote: Can't we come up with a version of dma_request_slave_channel that works both ways for now: mcspi_dma-dma_rx = dma_request_slave_channel_compat(mask, omap_dma_filter_fn, sig, master-dev, mcspi_dma-dma_rx_ch_name); ... Then it's just question of patching away two lines later on rather than having to add all this if else to all the drivers first, then patching it away again. I think that something like that is workable with the implementation simply checking for of_node to do the right thing. Yes, I think it would be better to have common API but underneath two implementations in transitional phase. -- ~Vinod -- 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: [RFC PATCH 08/13] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC
On Fri, 2012-09-21 at 19:47 +0100, Russell King - ARM Linux wrote: On Fri, Sep 21, 2012 at 10:45:29PM +0530, S, Venkatraman wrote: On Thu, Sep 20, 2012 at 8:13 PM, Matt Porter mpor...@ti.com wrote: The EDMA DMAC has a hardware limitation that prevents supporting scatter gather lists with any number of segments. Since the EDMA DMA Engine driver sets the maximum segments to 16, we do the same. Note: this can be removed once the DMA Engine API supports an API to query the DMAC's segment limitations. I wouldn't want to bind the properties of EDMA to omap_hsmmc as this patch suggests. Why don't we have a max_segs property, which when explicitly specified in DT, will override the default ? Why not have a generic way that DMA engine can export these kinds of properties? We discussed this at KS. I was of opinion that DMA engine should export controller and channel capabilities as part of the channel it returns. Some folks had an opinion that they already know how to use controller so may not be very helpful, but if it is going to help (which I think), i have a patch for this :) -- ~Vinod -- 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 v2 2/2] omap3isp: Configure CSI-2 phy based on platform data
Hi Sakari,
Thanks for the patch.
On Thursday 27 September 2012 00:50:36 Sakari Ailus wrote:
Configure CSI-2 phy based on platform data in the ISP driver. For that, the
new V4L2_CID_IMAGE_SOURCE_PIXEL_RATE control is used. Previously the same
was configured from the board code.
This patch is dependent on omap3: Provide means for changing CSI2 PHY
configuration.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/omap3isp/isp.h |3 -
drivers/media/platform/omap3isp/ispcsiphy.c | 161 +---
drivers/media/platform/omap3isp/ispcsiphy.h | 10 --
3 files changed, 90 insertions(+), 84 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h index 8be7487..a2f992c 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -127,9 +127,6 @@ struct isp_reg {
struct isp_platform_callback {
u32 (*set_xclk)(struct isp_device *isp, u32 xclk, u8 xclksel);
- int (*csiphy_config)(struct isp_csiphy *phy,
- struct isp_csiphy_dphy_cfg *dphy,
- struct isp_csiphy_lanes_cfg *lanes);
};
/*
diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c
b/drivers/media/platform/omap3isp/ispcsiphy.c index 348f67e..1d16e66 100644
--- a/drivers/media/platform/omap3isp/ispcsiphy.c
+++ b/drivers/media/platform/omap3isp/ispcsiphy.c
@@ -28,41 +28,13 @@
#include linux/device.h
#include linux/regulator/consumer.h
+#include mach/control.h
+
#include isp.h
#include ispreg.h
#include ispcsiphy.h
/*
- * csiphy_lanes_config - Configuration of CSIPHY lanes.
- *
- * Updates HW configuration.
- * Called with phy-mutex taken.
- */
-static void csiphy_lanes_config(struct isp_csiphy *phy)
-{
- unsigned int i;
- u32 reg;
-
- reg = isp_reg_readl(phy-isp, phy-cfg_regs, ISPCSI2_PHY_CFG);
-
- for (i = 0; i phy-num_data_lanes; i++) {
- reg = ~(ISPCSI2_PHY_CFG_DATA_POL_MASK(i + 1) |
- ISPCSI2_PHY_CFG_DATA_POSITION_MASK(i + 1));
- reg |= (phy-lanes.data[i].pol
- ISPCSI2_PHY_CFG_DATA_POL_SHIFT(i + 1));
- reg |= (phy-lanes.data[i].pos
- ISPCSI2_PHY_CFG_DATA_POSITION_SHIFT(i + 1));
- }
-
- reg = ~(ISPCSI2_PHY_CFG_CLOCK_POL_MASK |
- ISPCSI2_PHY_CFG_CLOCK_POSITION_MASK);
- reg |= phy-lanes.clk.pol ISPCSI2_PHY_CFG_CLOCK_POL_SHIFT;
- reg |= phy-lanes.clk.pos ISPCSI2_PHY_CFG_CLOCK_POSITION_SHIFT;
-
- isp_reg_writel(phy-isp, reg, phy-cfg_regs, ISPCSI2_PHY_CFG);
-}
-
-/*
* csiphy_power_autoswitch_enable
* @enable: Sets or clears the autoswitch function enable flag.
*/
@@ -107,46 +79,32 @@ static int csiphy_set_power(struct isp_csiphy *phy, u32
power) }
/*
- * csiphy_dphy_config - Configure CSI2 D-PHY parameters.
- *
- * Called with phy-mutex taken.
+ * TCLK values are OK at their reset values
*/
-static void csiphy_dphy_config(struct isp_csiphy *phy)
-{
- u32 reg;
-
- /* Set up ISPCSIPHY_REG0 */
- reg = isp_reg_readl(phy-isp, phy-phy_regs, ISPCSIPHY_REG0);
-
- reg = ~(ISPCSIPHY_REG0_THS_TERM_MASK |
- ISPCSIPHY_REG0_THS_SETTLE_MASK);
- reg |= phy-dphy.ths_term ISPCSIPHY_REG0_THS_TERM_SHIFT;
- reg |= phy-dphy.ths_settle ISPCSIPHY_REG0_THS_SETTLE_SHIFT;
-
- isp_reg_writel(phy-isp, reg, phy-phy_regs, ISPCSIPHY_REG0);
-
- /* Set up ISPCSIPHY_REG1 */
- reg = isp_reg_readl(phy-isp, phy-phy_regs, ISPCSIPHY_REG1);
-
- reg = ~(ISPCSIPHY_REG1_TCLK_TERM_MASK |
- ISPCSIPHY_REG1_TCLK_MISS_MASK |
- ISPCSIPHY_REG1_TCLK_SETTLE_MASK);
- reg |= phy-dphy.tclk_term ISPCSIPHY_REG1_TCLK_TERM_SHIFT;
- reg |= phy-dphy.tclk_miss ISPCSIPHY_REG1_TCLK_MISS_SHIFT;
- reg |= phy-dphy.tclk_settle ISPCSIPHY_REG1_TCLK_SETTLE_SHIFT;
-
- isp_reg_writel(phy-isp, reg, phy-phy_regs, ISPCSIPHY_REG1);
-}
+#define TCLK_TERM0
+#define TCLK_MISS1
+#define TCLK_SETTLE 14
-static int csiphy_config(struct isp_csiphy *phy,
- struct isp_csiphy_dphy_cfg *dphy,
- struct isp_csiphy_lanes_cfg *lanes)
+static int omap3isp_csiphy_config(struct isp_csiphy *phy)
{
+ struct isp_csi2_device *csi2 = phy-csi2;
+ struct isp_pipeline *pipe = to_isp_pipeline(csi2-subdev.entity);
+ struct isp_v4l2_subdevs_group *subdevs = pipe-external-host_priv;
+ struct isp_csiphy_lanes_cfg *lanes;
+ int csi2_ddrclk_khz;
unsigned int used_lanes = 0;
unsigned int i;
+ unsigned int phy_num;
+ u32 reg;
+
+ if (subdevs-interface == ISP_INTERFACE_CCP2B_PHY1
+ || subdevs-interface == ISP_INTERFACE_CCP2B_PHY2)
+ lanes = subdevs-bus.ccp2.lanecfg;
+ else
+ lanes =
Re: [PATCH v2 2/2] omap3isp: Configure CSI-2 phy based on platform data
Hi Tony, On Wednesday 26 September 2012 15:00:19 Tony Lindgren wrote: Moi Sakari * Sakari Ailus sakari.ai...@iki.fi [120926 14:51]: Configure CSI-2 phy based on platform data in the ISP driver. For that, the new V4L2_CID_IMAGE_SOURCE_PIXEL_RATE control is used. Previously the same was configured from the board code. This patch is dependent on omap3: Provide means for changing CSI2 PHY configuration. Can you please do one more patch to get rid of the last remaining cpu_is_omap check in drivers/media/platform/omap3isp/isp.c? I'm working on that, I'll submit a patch. That data should come from platform_data (or device tree) as we going to make cpu_is_omap privat to mach-omap2. -- Regards, Laurent Pinchart -- 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: Help needed with remaining plat headers
Hi Tony, On Fri, Sep 21, 2012 at 4:59 AM, Tony Lindgren t...@atomide.com wrote: Hi all, With the recent pull request I sent for v3.7, we now have pretty much all the mach includes fixed up for omap2+ for single zImage support. We still have quite a few plat headers that we need to sort out manually. Please take a look at the following list, and reply to this thread if you are working on patches moving one of the headers in the list so we can coordinate things. The rules are simple for most of them: 1. For driver related data, the header should now be in include/linux/platform_data/*.h 2. For mach-omap2 specific things, the headers should be in arch/arm/mach-omap2. 3. Drivers should not include anything from plat or mach. I'll be looking into getting rid of cpu.h etc for v3.8 merge window, but won't be looking much at the driver related headers. So some help would be appreciated here :) Regards, Tony $ ls arch/arm/plat-omap/include/plat/ clkdev_omap.h clock.h common.h cpu.h dma-44xx.h dma.h As a part of clean up I am looking at dma.h and dma-44xx.h files ll send you patches once cleanup and testing is done. Thanks Lokesh dmtimer.h fpga.h gpmc.h i2c.h iommu2.h iommu.h iopgtable.h iovmm.h led.h mailbox.h menelaus.h mmc.h multi.h omap_device.h omap_hwmod.h omap-pm.h omap-secure.h omap-serial.h prcm.h sdrc.h serial.h sram.h tc.h timex.h uncompress.h usb.h vram.h vrfb.h -- 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 -- 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 v7 08/11] ARM: OMAP2+: gpmc: generic timing calculation
Hi Jon,
On Thu, Sep 27, 2012 at 08:54:22, Hunter, Jon wrote:
On 09/19/2012 08:23 AM, Afzal Mohammed wrote:
+Dependency of peripheral timings on gpmc timings:
+
+cs_on: t_ceasu
Thanks for adding these details. Could be good to clarify that the
left-hand side parameters are the gpmc register fields and the
right-hand side are the timing parameters these are calculated using.
Ok
Also, given that this is in documentation for completeness it could be
good to somewhere state what t_ceasu means. For the gpmc register
field description may be we could give a reference to an OMAP document.
Yes, it has been mentioned, as quoted below, reason it has not been
mentioned here is to avoid duplication. I will add TRM reference.
+Note: Many of gpmc timings are dependent on other gpmc timings (a few
+mentioned above, refer timing routine for more details. To know what
+these peripheral timings correspond to, please see explanations in
+struct gpmc_device_timings definition.
+struct gpmc_device_timings {
+ u32 t_ceasu;/* address setup to CS valid */
+adv_rd_off: t_avdp_r, t_avdh(s*)
+oe_on: t_oeasu, t_aavdh(a**), t_ach(s), cyc_aavdh_oe(s)
Would it be better to have ...
oe_on (sync): t_oeasu, t_ach(*), cyc_aavdh_oe
oe_on (async):t_oeasu, t_aavdh(*)
Ok
* - optional
I assume that the hold times from the clock (t_ach and t_aavdh) are used
for fine tuning if the peripheral requires this, but a user adding a new
device would not be required to specify these, where as t_oeasu is
mandatory.
It depends on the peripheral, t_oeasu in not used for OneNAND, tusb sync,
so I prefer not mentioning any timing as optional or mandatory.
Or maybe should the timings be grouped as ...
General
Read Async
Read Async Address/Data Multiplexed
Read Sync
Read Sync Address/Data Multiplexed
Write Async
Write Async Address/Data Multiplexed
Write Sync
Write Sync Address/Data Multiplexed
There may be some duplication but it will be clear where things like ADV
timing applies.
I would prefer to keep it concise, but no strong opinion on it, if you
prefer as above, I will change it.
+/* can the cycles be avoided ? */
Nit should this be marked with a TODO?
+ /* mux check required ? */
Nit should this be marked with a TODO?
Marking XXX should Ok, right ?, reason is that they are not
kept as TODO, but rather as pointers to may be possible
improvements
+ gpmc_t-adv_rd_off = gpmc_round_ps_to_ticks(temp);
Any reason why we can't return ns in the above function? Or make this
function gpmc_round_ps_to_ns()? Then we could avoid having
gpmc_convert_ps_to_ns() below.
Calculation in ps is required to get more accurate results.
Calculating in ns was the reason for issue faced on N800 for Tony
with previous version.
I will explain what would have happened with v6 on N800,
i.e. using ns values,
Based on logs from Tony, gpmc clk was 9ns, actually it would
have been somewhere around 9115ps.
Take below timings of previous version in tusb async case
gpmc_t-oe_on = gpmc_round_ps_to_ticks(temp) / 1000;
/* access */
temp = max_t(u32, dev_t-t_iaa, /* remove t_iaa in async ? */
gpmc_t-oe_on * 1000 + dev_t-t_oe);
temp = max_t(u32, temp,
gpmc_t-cs_on * 1000 + dev_t-t_ce);
temp = max_t(u32, temp,
gpmc_t-adv_on * 1000 + dev_t-t_aa);
gpmc_t-access = gpmc_round_ps_to_ticks(temp) / 1000;
Upon calculating we get,
oe_on = 63805 / 1000 = 63
and for access (t_oe = 300, t_ce = t_aa = t_iaa = 0),
temp = 63 * 1000 + 300 = 63300
access = 63300 / 1000 = 63
Here we get oe_on as well as access as 7 ticks, but access should
have been 8 ticks, which is what we will get by using ps values,
i.e. as in this version, as below,
gpmc_t-oe_on = gpmc_round_ps_to_ticks(temp);
/* access */
temp = max_t(u32, dev_t-t_iaa, /* remove t_iaa in async ? */
gpmc_t-oe_on + dev_t-t_oe);
temp = max_t(u32, temp,
gpmc_t-cs_on + dev_t-t_ce);
temp = max_t(u32, temp,
gpmc_t-adv_on + dev_t-t_aa);
gpmc_t-access = gpmc_round_ps_to_ticks(temp);
I believe it is always better to go with higher resolution.
+ gpmc_convert_ps_to_ns(gpmc_t);
I am wondering if we could avoid this above function and then ...
This will be removed once it is confirmed that all the peripherals
using custom runtime calculation can work with this generic
routine. Then all calculation would be purely in ps.
Right now converting ps to ns has been kept only to be compatible
with custom routines and so that we can easily go back to custom
routines in case of any issues, quoting relevant commit message below,
Timings are calculated in ps to prevent rounding errors and
converted to ns at final stage so that these values can be
Re: Help needed with remaining plat headers
On Thu, 2012-09-20 at 16:29 -0700, Tony Lindgren wrote: Hi all, With the recent pull request I sent for v3.7, we now have pretty much all the mach includes fixed up for omap2+ for single zImage support. We still have quite a few plat headers that we need to sort out manually. Please take a look at the following list, and reply to this thread if you are working on patches moving one of the headers in the list so we can coordinate things. The rules are simple vram.h vrfb.h I'll work on these ones. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH V2 0/2] OMAPDSS: Enable dynamic debug printing
On Wed, Sep 26, 2012 at 7:59 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: This doesn't work quite correctly. The problem is in dss.h, where we define DEBUG if CONFIG_OMAP2_DSS_DEBUG_SUPPORT is set. The thing is, DEBUG should be defined before including the kernel headers where the pr_debug etc are defined. So if you try the patches without dynamic debugging enabled, you won't get any debug outputs at all, even if CONFIG_OMAP2_DSS_DEBUG_SUPPORT is set. And for dynamic debug, the Kconfig help says: If a source file is compiled with DEBUG flag set, any pr_debug() calls in it are enabled by default, but can be disabled at runtime as below. Note that DEBUG flag is turned on by many CONFIG_*DEBUG* options. So if we have CONFIG_OMAP2_DSS_DEBUG_SUPPORT set, all the pr_debugs should be enabled by default, which is not the case, again because DEBUG is defined too late. I think setting DEBUG in dss.h should be removed, and instead DEBUG should be set in the makefile if CONFIG_OMAP2_DSS_DEBUG_SUPPORT is set. Tomi Well the documentation lags in describing about the DEBUG flag. I should have checked DYNAMIC_DEBUG in Kconfig and pr_debug definition in printk.h file. #if defined(CONFIG_DYNAMIC_DEBUG) /* dynamic_pr_debug() uses pr_fmt() internally so we don't need it here */ #define pr_debug(fmt, ...) \ dynamic_pr_debug(fmt, ##__VA_ARGS__) #elif defined(DEBUG) #define pr_debug(fmt, ...) \ printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__) #else #define pr_debug(fmt, ...) \ no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__) #endif As per the definition above pr_debug is dynamic with CONFIG_DYNAMIC_DEBUG set or else with DEBUG set it is just a normal kernel debug printk as you have mentioned. I still don't get how even if DEBUG is set before DSSDBG() is defined in dss.c pr_debug() fails to enable. Well anyways, how to do the same in the Makefile? I tried adding ccflags-$(CONFIG_OMAP2_DSS_DEBUG_SUPPORT) += -DEBUG to makefile in dss directory but of no use. -- Chandrabhanu Mahapatra Texas Instruments India Pvt. Ltd. -- 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] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
Op 26 sep. 2012, om 13:37 heeft Hebbar, Gururaja gururaja.heb...@ti.com het volgende geschreven: On Wed, Sep 12, 2012 at 17:32:38, Hebbar, Gururaja wrote: On Wed, Sep 12, 2012 at 14:19:51, S, Venkatraman wrote: On Tue, Sep 4, 2012 at 6:39 PM, Hebbar, Gururaja gururaja.heb...@ti.com wrote: HSMMC IP on AM33xx need a special setting to handle High-speed cards. Other platforms like TI81xx, OMAP4 may need this as-well. This depends on the HSMMC IP timing closure done for the high speed cards. From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation) The MMC/SD/SDIO output signals can be driven on either falling edge or rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows to reach better timing performance, and thus to increase data transfer frequency. There are few pre-requisites for enabling the HSPE bit - Controller should support High-Speed-Enable Bit and - Controller should not be using DDR Mode and - Controller should advertise that it supports High Speed in capabilities register and - MMC/SD clock coming out of controller 25MHz The patch is well written. But then, I don't see a need for a DT binding for this feature. My reasons for DT Binding 1. Not all platforms using this driver has this bit (OMAP2) 2. Not all platforms using this driver needs this bit to be enabled (OMAP4) 3. Platforms which require this bit this to be set needs a method to inform driver. In order to not disturb old/unsupported platforms, I chose this DT method. By definition, HS implies 25MHz or above, so that check seems to be redundant as well. There are chances that the platform Max Clock output from HSMMC IP is than 25 MHz even if the card is High Speed. In such cases it would be better to Confirm that the Clock output is actually 25 MHz Kindly correct me if I am wrong. Meanwhile, I'll check with HSPE enabled on OMAP. Gentle Ping. Matt Poter recently submitted EDMA related patches as RFC. He confirmed that basic mmc is working on AM335x with his edma patches. Above patch is required to get High-speed cards working on AM335x. I haven't seen any review comments for this. Can this be pulled in for 3.7? I had trouble applying this to 3.6-rc7, is that a known problem and should I try linux-next? regards, Koen-- 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 V2 0/2] OMAPDSS: Enable dynamic debug printing
On Thu, 2012-09-27 at 16:20 +0530, Mahapatra, Chandrabhanu wrote: On Wed, Sep 26, 2012 at 7:59 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: This doesn't work quite correctly. The problem is in dss.h, where we define DEBUG if CONFIG_OMAP2_DSS_DEBUG_SUPPORT is set. The thing is, DEBUG should be defined before including the kernel headers where the pr_debug etc are defined. So if you try the patches without dynamic debugging enabled, you won't get any debug outputs at all, even if CONFIG_OMAP2_DSS_DEBUG_SUPPORT is set. And for dynamic debug, the Kconfig help says: If a source file is compiled with DEBUG flag set, any pr_debug() calls in it are enabled by default, but can be disabled at runtime as below. Note that DEBUG flag is turned on by many CONFIG_*DEBUG* options. So if we have CONFIG_OMAP2_DSS_DEBUG_SUPPORT set, all the pr_debugs should be enabled by default, which is not the case, again because DEBUG is defined too late. I think setting DEBUG in dss.h should be removed, and instead DEBUG should be set in the makefile if CONFIG_OMAP2_DSS_DEBUG_SUPPORT is set. Tomi Well the documentation lags in describing about the DEBUG flag. I should have checked DYNAMIC_DEBUG in Kconfig and pr_debug definition in printk.h file. #if defined(CONFIG_DYNAMIC_DEBUG) /* dynamic_pr_debug() uses pr_fmt() internally so we don't need it here */ #define pr_debug(fmt, ...) \ dynamic_pr_debug(fmt, ##__VA_ARGS__) #elif defined(DEBUG) #define pr_debug(fmt, ...) \ printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__) #else #define pr_debug(fmt, ...) \ no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__) #endif As per the definition above pr_debug is dynamic with CONFIG_DYNAMIC_DEBUG set or else with DEBUG set it is just a normal kernel debug printk as you have mentioned. I still don't get how even if DEBUG is set before DSSDBG() is defined in dss.c pr_debug() fails to enable. Because printk.h is included without DEBUG, thus pr_debug is defined as no_printk. Well anyways, how to do the same in the Makefile? I tried adding ccflags-$(CONFIG_OMAP2_DSS_DEBUG_SUPPORT) += -DEBUG to makefile in dss directory but of no use. -D option for the compiler is used to set defines. So it should be -DDEBUG Tomi signature.asc Description: This is a digitally signed message part
RE: [PATCH] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
On Thu, Sep 27, 2012 at 16:31:14, Koen Kooi wrote: Op 26 sep. 2012, om 13:37 heeft Hebbar, Gururaja gururaja.heb...@ti.com het volgende geschreven: On Wed, Sep 12, 2012 at 17:32:38, Hebbar, Gururaja wrote: On Wed, Sep 12, 2012 at 14:19:51, S, Venkatraman wrote: On Tue, Sep 4, 2012 at 6:39 PM, Hebbar, Gururaja gururaja.heb...@ti.com wrote: HSMMC IP on AM33xx need a special setting to handle High-speed cards. Other platforms like TI81xx, OMAP4 may need this as-well. This depends on the HSMMC IP timing closure done for the high speed cards. From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation) The MMC/SD/SDIO output signals can be driven on either falling edge or rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows to reach better timing performance, and thus to increase data transfer frequency. There are few pre-requisites for enabling the HSPE bit - Controller should support High-Speed-Enable Bit and - Controller should not be using DDR Mode and - Controller should advertise that it supports High Speed in capabilities register and - MMC/SD clock coming out of controller 25MHz The patch is well written. But then, I don't see a need for a DT binding for this feature. My reasons for DT Binding 1. Not all platforms using this driver has this bit (OMAP2) 2. Not all platforms using this driver needs this bit to be enabled (OMAP4) 3. Platforms which require this bit this to be set needs a method to inform driver. In order to not disturb old/unsupported platforms, I chose this DT method. By definition, HS implies 25MHz or above, so that check seems to be redundant as well. There are chances that the platform Max Clock output from HSMMC IP is than 25 MHz even if the card is High Speed. In such cases it would be better to Confirm that the Clock output is actually 25 MHz Kindly correct me if I am wrong. Meanwhile, I'll check with HSPE enabled on OMAP. Gentle Ping. Matt Poter recently submitted EDMA related patches as RFC. He confirmed that basic mmc is working on AM335x with his edma patches. Above patch is required to get High-speed cards working on AM335x. I haven't seen any review comments for this. Can this be pulled in for 3.7? I had trouble applying this to 3.6-rc7, is that a known problem and should I try linux-next? I just applied it applied it on Linux-next/master (locally merged with linux-omap-dt branch). It applied without any issues. regards, Koen Regards, Gururaja -- 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_v2] watchdog: Convert twl4030_wdt to watchdog core
Hi On 09/11/2012 09:01 AM, Jarkko Nikula wrote: Convert the twl4030_wdt watchdog driver to watchdog core. While at there use devm_kzalloc and set the default timeout in order to be able test this driver with a simple shell script. Signed-off-by: Jarkko Nikulajarkko.nik...@jollamobile.com Tested-by: Aaro Koskinenaaro.koski...@iki.fi --- v2: - select WATCHDOG_CORE in Kconfig was accidentally put to to OMAP_WATCHDOG instead of TWL4030_WATCHDOG. Thanks to Aaro Koskinenaaro.koski...@iki.fi for noticing. - Added Aaro's Tested-by --- drivers/watchdog/Kconfig |1 + drivers/watchdog/twl4030_wdt.c | 183 2 files changed, 35 insertions(+), 149 deletions(-) Gentle ping if this got lost and if I need to repost, fix, etc. -- Jarkko -- 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
McSPI : MTD framework Issue
Loading omap2_mcspi.ko and m25p80.ko modules. Trying to remove SPI module(omap2_mcspi.ko) during the I/O of SPI. The module should not be removed since it is still in use. But when run this test, bunch of kernel errors occurs. 'lsmod' doesn't show the spi module anymore, but flash module(m25p80.ko) is still loaded there. So, trying to create dependencies in SPI Framework and MTD Framework. Is this problem seen elsewhere, as I am using Linux 2.6.37+ Image. -- 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: ARM: OMAP: fix new sparse warnings
Hi Paul, On 09/25/12 01:09, Paul Walmsley wrote: Commit e54adb1e79762d3591459e5b0e9b9ff578e33fdb (ARM: OMAP: omap3evm: cleanup revision bits) adds a new sparse[1] warning: arch/arm/mach-omap2/board-omap3evm.c:90:4: warning: symbol 'get_omap3_evm_rev' was not declared. Should it be static? This symbol no longer appears to be used outside this file, so mark it static and remove the export. Commit 801475ccb2b2c1928b22aec4b9e5285d9e347602 (ARM: OMAP: move debug_card_init() function) results in the following new sparse[1] warning: arch/arm/plat-omap/debug-devices.c:71:12: warning: symbol 'debug_card_init' was not declared. Should it be static? Fix by including the proper header file. ... 1. https://sparse.wiki.kernel.org/index.php/Main_Page Yeah, my compiler did not emit those... Thanks for the fix! Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Igor Grinberg grinb...@compulab.co.il Cc: Tony Lindgren t...@atomide.com Acked-by: Igor Grinberg grinb...@compulab.co.il -- Regards, Igor. -- 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: OMAP baseline test results for v3.6-rc7
On 09/24/12 21:21, Paul Walmsley wrote: Here are some basic OMAP boot and power management test results for v3.6-rc6: http://www.pwsan.com/omap/testlogs/test_v3.6-rc6/20120918101040/ Some observations: Boot tests: * CM-T3517: L3 in-band error with IPSS during boot - Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2 - Longstanding issue; does not occur on the 3517EVM I'll be able to put some human resources on investigating this in a couple of weeks hopefully. Currently, it does not affect all boards (using the same boot loader) and does not look that it interferes with any functionality later in the boot or runtime. * 3517EVM CM-T3517: boot hangs - Probably due to the use of NFS root; there are likely some Kconfig, board file, and PM issues with EMAC Have you tried the nohlt boot parameter? It looks like the wfi is killing those SoCs once you use EMAC. PM tests: * 37xx EVM: CORE not entering dynamic off-idle - Cause unknown; dynamic retention-idle seems to work; system suspend to off works * 3730 Beagle XM: does not serial wake from off-idle suspend when console UART doesn't clock gate (debug ignore_loglevel) - Not shown in the current test logs; cause unknown * 4430ES2 Panda: UART corruption during long transmit buffers - Presumably due to either a missing hardware workaround or a bug in the OMAP serial driver Other: * RCU stall messages appear if boards are booted into a minimal userspace and left to sit for a few minutes - Fixed by http://marc.info/?l=linux-arm-kernelm=134835120600590w=2 Changes from v3.6-rc6 (test 20120918101040): (see http://www.pwsan.com/omap/testlogs/test_v3.6-rc6/20120918101040/ ) - Added comments about RCU stalls, appearing since at least v3.6-rc3 - Updated CM-T3517 USB OTG (really IPSS) comment object size (delta in bytes from test_v3.6-rc6 (5698bd757d55b1bb87edd1a9744ab09c142abfc2)): text data bss total kernel -328 +72 0-256 2430_testconfig -16 +16 0 0 5912osk_testconfig -376 +72 0-304 am33xx_testconfig +64 +32 0 +96 n800_b_testconfig +80 +64 0+144 n800_multi_omap2xxx +80 +32 0+112 n800_testconfig +72 +80 0+152 omap1510_defconfig +40 +16 0 +56 omap1_defconfig +80 +64 0+144 omap2_4_testconfig -376 +40 0-336 omap2plus_defconfig -376 +72 0-304 omap2plus_defconfig_cpupm +20 +72 0 +92 omap2plus_no_pm +20+8 0 +28 omap3_4_testconfig +140 +72 0+212 omap3_testconfig +20 +40 0 +60 omap4_testconfig -40 +72 0 +32 rmk_omap3430_ldp_oldconfig -200+8 0-192 rmk_omap4430_sdp_oldconfig - 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 -- Regards, Igor. -- 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 v2 0/2] usb: phy: add usb3 phy driver
Added a driver for usb3 phy that handles the interaction between usb phy device and dwc3 controller. Currently writing to control module register is taken care in this driver which will be removed once the control module driver is in place. Changes from v1: * Added missing clk_put() * Remove the patches usb: dwc3: Fix gadget pullup in SS mode and usb: phy: omap-usb3: Decrease the number of transitions to recovery. Those are actually WA for hw issues which will be fixed in ES2. * Removed the *has960mhzclk* property This patch series was rebased on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv However the dependent modules are not yet upstreamed and hence only compile tested in this tree Kishon Vijay Abraham I (2): usb: phy: add a new driver for usb3 phy usb: phy: omap-usb2: enable 960Mhz clock for omap5 Documentation/devicetree/bindings/usb/usb-phy.txt | 18 + drivers/usb/phy/Kconfig |9 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-usb2.c | 18 +- drivers/usb/phy/omap-usb3.c | 412 + include/linux/usb/omap_usb.h | 33 ++ 6 files changed, 489 insertions(+), 2 deletions(-) create mode 100644 drivers/usb/phy/omap-usb3.c -- 1.7.9.5 -- 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 v2 2/2] usb: phy: omap-usb2: enable 960Mhz clock for omap5
usb_otg_ss_refclk960m is needed for usb2 phy present in omap5. For
omap4, the clk_get of this clock will fail since it does not have this
clock.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/phy/omap-usb2.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index d36c282..5512207 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -190,6 +190,12 @@ static int __devinit omap_usb2_probe(struct
platform_device *pdev)
}
clk_prepare(phy-wkupclk);
+ phy-optclk = devm_clk_get(phy-dev, usb_otg_ss_refclk960m);
+ if (IS_ERR(phy-optclk))
+ dev_vdbg(pdev-dev, unable to get refclk960m\n);
+ else
+ clk_prepare(phy-optclk);
+
usb_add_phy(phy-phy, USB_PHY_TYPE_USB2);
platform_set_drvdata(pdev, phy);
@@ -204,6 +210,7 @@ static int __devexit omap_usb2_remove(struct
platform_device *pdev)
struct omap_usb *phy = platform_get_drvdata(pdev);
clk_unprepare(phy-wkupclk);
+ clk_unprepare(phy-optclk);
usb_remove_phy(phy-phy);
return 0;
@@ -217,6 +224,7 @@ static int omap_usb2_runtime_suspend(struct device *dev)
struct omap_usb *phy = platform_get_drvdata(pdev);
clk_disable(phy-wkupclk);
+ clk_disable(phy-optclk);
return 0;
}
@@ -228,10 +236,16 @@ static int omap_usb2_runtime_resume(struct device *dev)
struct omap_usb *phy = platform_get_drvdata(pdev);
ret = clk_enable(phy-wkupclk);
- if (ret 0)
+ if (ret 0) {
dev_err(phy-dev, Failed to enable wkupclk %d\n, ret);
+ return ret;
+ }
- return ret;
+ ret = clk_enable(phy-optclk);
+ if (ret 0)
+ dev_vdbg(phy-dev, Failed to enable optclk %d\n, ret);
+
+ return 0;
}
static const struct dev_pm_ops omap_usb2_pm_ops = {
--
1.7.9.5
--
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 v2 1/2] usb: phy: add a new driver for usb3 phy
Added a driver for usb3 phy that handles the interaction between usb phy
device and dwc3 controller.
This also includes device tree support for usb3 phy driver and
the documentation with device tree binding information is updated.
Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Moiz Sonasath m-sonas...@ti.com
---
Documentation/devicetree/bindings/usb/usb-phy.txt | 18 +
drivers/usb/phy/Kconfig |9 +
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/omap-usb3.c | 412 +
include/linux/usb/omap_usb.h | 33 ++
5 files changed, 473 insertions(+)
create mode 100644 drivers/usb/phy/omap-usb3.c
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 80d4148..7c5fd89 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -15,3 +15,21 @@ usb2phy@4a0ad080 {
reg = 0x4a0ad080 0x58,
0x4a002300 0x4;
};
+
+OMAP USB3 PHY
+
+Required properties:
+ - compatible: Should be ti,omap-usb3
+ - reg : Address and length of the register set for the device. Also
+add the address of control module phy power register until a driver for
+control module is added
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb3phy@4a084400 {
+ compatible = ti,omap-usb3;
+ reg = 0x0x4a084400 0x80,
+ 0x4a084800 0x64,
+ 0x4a084c00 0x40,
+ 0x4a002370 0x4;
+};
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 63c339b..353dc0c 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -13,6 +13,15 @@ config OMAP_USB2
The USB OTG controller communicates with the comparator using this
driver.
+config OMAP_USB3
+ tristate OMAP USB3 PHY Driver
+ select USB_OTG_UTILS
+ help
+ Enable this to support the USB3 PHY that is part of SOC. This
+ driver takes care of all the PHY functionality apart from comparator.
+ The USB OTG controller communicates with the comparator using this
+ driver.
+
config USB_ISP1301
tristate NXP ISP1301 USB transceiver support
depends on USB || USB_GADGET
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index b069f29..973b1e6 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -5,6 +5,7 @@
ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG
obj-$(CONFIG_OMAP_USB2)+= omap-usb2.o
+obj-$(CONFIG_OMAP_USB3)+= omap-usb3.o
obj-$(CONFIG_USB_ISP1301) += isp1301.o
obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
diff --git a/drivers/usb/phy/omap-usb3.c b/drivers/usb/phy/omap-usb3.c
new file mode 100644
index 000..cecfbd4
--- /dev/null
+++ b/drivers/usb/phy/omap-usb3.c
@@ -0,0 +1,412 @@
+/*
+ * omap-usb3 - USB PHY, talking to dwc3 controller in OMAP.
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/usb/omap_usb.h
+#include linux/of.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/pm_runtime.h
+#include linux/delay.h
+
+#defineNUM_SYS_CLKS5
+#definePLL_STATUS 0x0004
+#definePLL_GO 0x0008
+#definePLL_CONFIGURATION1 0x000C
+#definePLL_CONFIGURATION2 0x0010
+#definePLL_CONFIGURATION3 0x0014
+#definePLL_CONFIGURATION4 0x0020
+
+#definePLL_REGM_MASK 0x001FFE00
+#definePLL_REGM_SHIFT 0x9
+#definePLL_REGM_F_MASK 0x0003
+#definePLL_REGM_F_SHIFT0x0
+#definePLL_REGN_MASK 0x01FE
+#definePLL_REGN_SHIFT 0x1
+#definePLL_SELFREQDCO_MASK 0x000E
+#definePLL_SELFREQDCO_SHIFT0x1
+#definePLL_SD_MASK 0x0003FC00
+#definePLL_SD_SHIFT0x9
+#define
Re: [PATCH v2 1/2] usb: phy: add a new driver for usb3 phy
On Thu, Sep 27, 2012 at 07:34:07PM +0530, Kishon Vijay Abraham I wrote:
+static int omap5_usb_phy_power(struct omap_usb *phy, bool on)
+{
+ u32 val;
+ unsigned long rate;
+ struct clk *sys_clk;
+
+ sys_clk = clk_get(NULL, sys_clkin);
+ if (IS_ERR(sys_clk)) {
+ pr_err(%s: unable to get sys_clkin\n, __func__);
+ return -EINVAL;
+ }
+
+ rate = clk_get_rate(sys_clk);
+ rate = rate/100;
+ clk_put(sys_clk);
Actually, you're supposed to hold on to the struct clk all the time your
driver is making use of that - you're not supposed to drop it.
That has several advantages: if clk_get() fails, then you're failing
earlier on (when the driver is being probed) and when some event occurs.
--
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/5] drivers: usb: phy: add a new driver for omap usb2 phy
On 09/25/2012 05:06 AM, ABRAHAM, KISHON VIJAY wrote: Hi, On Mon, Sep 24, 2012 at 6:45 PM, Rob Herring robherri...@gmail.com wrote: On 09/06/2012 09:57 AM, Kishon Vijay Abraham I wrote: All phy related programming like enabling/disabling the clocks, powering on/off the phy is taken care of by this driver. It is also used for OTG related functionality like srp. This also includes device tree support for usb2 phy driver and the documentation with device tree binding information is updated. Currently writing to control module register is taken care in this driver which will be removed once the control module driver is in place. Cc: Felipe Balbi ba...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- Documentation/devicetree/bindings/usb/usb-phy.txt | 17 ++ drivers/usb/phy/Kconfig |9 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-usb2.c | 271 + include/linux/usb/omap_usb.h | 46 include/linux/usb/phy_companion.h | 34 +++ 6 files changed, 378 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/usb-phy.txt create mode 100644 drivers/usb/phy/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt new file mode 100644 index 000..80d4148 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt This is a very generic name... @@ -0,0 +1,17 @@ +USB PHY + +OMAP USB2 PHY + +Required properties: + - compatible: Should be ti,omap-usb2 ...for a specific phy. However, I do think a generic binding to describe host ctrlr to phy connections is needed. + - reg : Address and length of the register set for the device. Also +add the address of control module dev conf register until a driver for +control module is added The dts should describe the h/w, not what you need for the current driver. The 2nd reg field does not belong here. Indeed. This was discussed and agreed upon as a interim solution till we have a control module driver in place to write to the control module register. Discussed where and agreed by who? I for one do not agree. Rob + +This is usually a subnode of ocp2scp to which it is connected. How is usb port to phy connection described? Currently the usb controller to phy connection is established only by type. We have a couple of patches being currently discussed in the list to establish the connection by phandle. https://patchwork.kernel.org/patch/1457801/ (Generic PHY Framework: devm_of_phy_get()) http://www.spinics.net/lists/linux-usb/msg69547.html Thanks Kishon -- 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] omap3isp: Replace cpu_is_omap3630() with ISP revision check
Drivers must not rely on cpu_is_omap* macros (they will soon become
private). Use the ISP revision instead to identify the hardware.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/omap3isp/isp.c | 25 -
1 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index d7aa513..6034dca 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -1345,10 +1345,7 @@ static int isp_enable_clocks(struct isp_device *isp)
* has to be twice of what is set on OMAP3430 to get
* the required value for cam_mclk
*/
- if (cpu_is_omap3630())
- divisor = 1;
- else
- divisor = 2;
+ divisor = isp-revision == ISP_REVISION_15_0 ? 1 : 2;
r = clk_enable(isp-clock[ISP_CLK_CAM_ICK]);
if (r) {
@@ -2093,7 +2090,11 @@ static int __devinit isp_probe(struct platform_device
*pdev)
isp-isp_csiphy1.vdd = regulator_get(pdev-dev, VDD_CSIPHY1);
isp-isp_csiphy2.vdd = regulator_get(pdev-dev, VDD_CSIPHY2);
- /* Clocks */
+ /* Clocks
+*
+* The ISP clock tree is revision-dependent. We thus need to enable ICLK
+* manually to read the revision before calling __omap3isp_get().
+*/
ret = isp_map_mem_resource(pdev, isp, OMAP3_ISP_IOMEM_MAIN);
if (ret 0)
goto error;
@@ -2102,6 +2103,16 @@ static int __devinit isp_probe(struct platform_device
*pdev)
if (ret 0)
goto error;
+ ret = clk_enable(isp-clock[ISP_CLK_CAM_ICK]);
+ if (ret 0)
+ goto error;
+
+ isp-revision = isp_reg_readl(isp, OMAP3_ISP_IOMEM_MAIN, ISP_REVISION);
+ dev_info(isp-dev, Revision %d.%d found\n,
+(isp-revision 0xf0) 4, isp-revision 0x0f);
+
+ clk_disable(isp-clock[ISP_CLK_CAM_ICK]);
+
if (__omap3isp_get(isp, false) == NULL) {
ret = -ENODEV;
goto error;
@@ -2112,10 +2123,6 @@ static int __devinit isp_probe(struct platform_device
*pdev)
goto error_isp;
/* Memory resources */
- isp-revision = isp_reg_readl(isp, OMAP3_ISP_IOMEM_MAIN, ISP_REVISION);
- dev_info(isp-dev, Revision %d.%d found\n,
-(isp-revision 0xf0) 4, isp-revision 0x0f);
-
for (m = 0; m ARRAY_SIZE(isp_res_maps); m++)
if (isp-revision == isp_res_maps[m].isp_rev)
break;
--
Regards,
Laurent Pinchart
--
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/5] drivers: usb: phy: add a new driver for omap usb2 phy
Hi, On Thu, Sep 27, 2012 at 7:54 PM, Rob Herring robherri...@gmail.com wrote: On 09/25/2012 05:06 AM, ABRAHAM, KISHON VIJAY wrote: Hi, On Mon, Sep 24, 2012 at 6:45 PM, Rob Herring robherri...@gmail.com wrote: On 09/06/2012 09:57 AM, Kishon Vijay Abraham I wrote: All phy related programming like enabling/disabling the clocks, powering on/off the phy is taken care of by this driver. It is also used for OTG related functionality like srp. This also includes device tree support for usb2 phy driver and the documentation with device tree binding information is updated. Currently writing to control module register is taken care in this driver which will be removed once the control module driver is in place. Cc: Felipe Balbi ba...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- Documentation/devicetree/bindings/usb/usb-phy.txt | 17 ++ drivers/usb/phy/Kconfig |9 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-usb2.c | 271 + include/linux/usb/omap_usb.h | 46 include/linux/usb/phy_companion.h | 34 +++ 6 files changed, 378 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/usb-phy.txt create mode 100644 drivers/usb/phy/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt new file mode 100644 index 000..80d4148 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt This is a very generic name... @@ -0,0 +1,17 @@ +USB PHY + +OMAP USB2 PHY + +Required properties: + - compatible: Should be ti,omap-usb2 ...for a specific phy. However, I do think a generic binding to describe host ctrlr to phy connections is needed. + - reg : Address and length of the register set for the device. Also +add the address of control module dev conf register until a driver for +control module is added The dts should describe the h/w, not what you need for the current driver. The 2nd reg field does not belong here. Indeed. This was discussed and agreed upon as a interim solution till we have a control module driver in place to write to the control module register. Discussed where and agreed by who? I for one do not agree. Please find the discussion @ https://patchwork.kernel.org/patch/1415261/ Thanks Kishon -- 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 v7 08/11] ARM: OMAP2+: gpmc: generic timing calculation
Hi Afzal,
On 09/27/2012 05:07 AM, Mohammed, Afzal wrote:
Hi Jon,
On Thu, Sep 27, 2012 at 08:54:22, Hunter, Jon wrote:
On 09/19/2012 08:23 AM, Afzal Mohammed wrote:
+Dependency of peripheral timings on gpmc timings:
+
+cs_on: t_ceasu
Thanks for adding these details. Could be good to clarify that the
left-hand side parameters are the gpmc register fields and the
right-hand side are the timing parameters these are calculated using.
Ok
Also, given that this is in documentation for completeness it could be
good to somewhere state what t_ceasu means. For the gpmc register
field description may be we could give a reference to an OMAP document.
Yes, it has been mentioned, as quoted below, reason it has not been
mentioned here is to avoid duplication. I will add TRM reference.
+Note: Many of gpmc timings are dependent on other gpmc timings (a few
+mentioned above, refer timing routine for more details. To know what
+these peripheral timings correspond to, please see explanations in
+struct gpmc_device_timings definition.
+struct gpmc_device_timings {
+ u32 t_ceasu;/* address setup to CS valid */
+adv_rd_off: t_avdp_r, t_avdh(s*)
+oe_on: t_oeasu, t_aavdh(a**), t_ach(s), cyc_aavdh_oe(s)
Would it be better to have ...
oe_on (sync):t_oeasu, t_ach(*), cyc_aavdh_oe
oe_on (async): t_oeasu, t_aavdh(*)
Ok
* - optional
I assume that the hold times from the clock (t_ach and t_aavdh) are used
for fine tuning if the peripheral requires this, but a user adding a new
device would not be required to specify these, where as t_oeasu is
mandatory.
It depends on the peripheral, t_oeasu in not used for OneNAND, tusb sync,
so I prefer not mentioning any timing as optional or mandatory.
Ok.
Or maybe should the timings be grouped as ...
General
Read Async
Read Async Address/Data Multiplexed
Read Sync
Read Sync Address/Data Multiplexed
Write Async
Write Async Address/Data Multiplexed
Write Sync
Write Sync Address/Data Multiplexed
There may be some duplication but it will be clear where things like ADV
timing applies.
I would prefer to keep it concise, but no strong opinion on it, if you
prefer as above, I will change it.
I think that if these represent the main use-case configurations this
could add some value.
+/* can the cycles be avoided ? */
Nit should this be marked with a TODO?
+ /* mux check required ? */
Nit should this be marked with a TODO?
Marking XXX should Ok, right ?, reason is that they are not
kept as TODO, but rather as pointers to may be possible
improvements
Sure, I don't have strong feelings about it but I would hope that at
some point this comment be removed.
+ gpmc_t-adv_rd_off = gpmc_round_ps_to_ticks(temp);
Any reason why we can't return ns in the above function? Or make this
function gpmc_round_ps_to_ns()? Then we could avoid having
gpmc_convert_ps_to_ns() below.
Calculation in ps is required to get more accurate results.
Calculating in ns was the reason for issue faced on N800 for Tony
with previous version.
I will explain what would have happened with v6 on N800,
i.e. using ns values,
Based on logs from Tony, gpmc clk was 9ns, actually it would
have been somewhere around 9115ps.
Take below timings of previous version in tusb async case
gpmc_t-oe_on = gpmc_round_ps_to_ticks(temp) / 1000;
/* access */
temp = max_t(u32, dev_t-t_iaa, /* remove t_iaa in async ? */
gpmc_t-oe_on * 1000 + dev_t-t_oe);
temp = max_t(u32, temp,
gpmc_t-cs_on * 1000 + dev_t-t_ce);
temp = max_t(u32, temp,
gpmc_t-adv_on * 1000 + dev_t-t_aa);
gpmc_t-access = gpmc_round_ps_to_ticks(temp) / 1000;
Upon calculating we get,
oe_on = 63805 / 1000 = 63
and for access (t_oe = 300, t_ce = t_aa = t_iaa = 0),
temp = 63 * 1000 + 300 = 63300
access = 63300 / 1000 = 63
Here we get oe_on as well as access as 7 ticks, but access should
have been 8 ticks, which is what we will get by using ps values,
i.e. as in this version, as below,
gpmc_t-oe_on = gpmc_round_ps_to_ticks(temp);
/* access */
temp = max_t(u32, dev_t-t_iaa, /* remove t_iaa in async ? */
gpmc_t-oe_on + dev_t-t_oe);
temp = max_t(u32, temp,
gpmc_t-cs_on + dev_t-t_ce);
temp = max_t(u32, temp,
gpmc_t-adv_on + dev_t-t_aa);
gpmc_t-access = gpmc_round_ps_to_ticks(temp);
I believe it is always better to go with higher resolution.
Ok, thanks for clarifying.
+ gpmc_convert_ps_to_ns(gpmc_t);
I am wondering if we could avoid this above function and then ...
This will be removed once it is confirmed that all the peripherals
using custom runtime calculation can work with this generic
routine. Then all calculation would be
[PATCH] ARM: OMAP4: hwmod data: Add McASP data port address space
McASP has a configuration port and a data port. This patch adds the address
space entry for the data port as described in the OMAP4 TRM.
Also, add names to the address spaces.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index f31f3bc..cb5b463 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4951,10 +4951,16 @@ static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcasp
= {
static struct omap_hwmod_addr_space omap44xx_mcasp_dma_addrs[] = {
{
+ .name = cfg,
.pa_start = 0x49028000,
.pa_end = 0x490283ff,
.flags = ADDR_TYPE_RT
},
+ {
+ .name = dat,
+ .pa_start = 0x4902A000,
+ .pa_end = 0x4902Afff,
+ },
{ }
};
--
1.7.5.4
--
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 0/6] ARM: OMAP: remove clock files in arch/arm/plat-omap
Remove clock-related header and C files from arch/arm/plat-omap. The intention is to support people working on the ARM single kernel image project, since the 'plat' symlink will no longer be available for OMAP-shared files. Intended for 3.8 cleanup. --- plat_clock_removal_cleanup_3.8 textdata bss dec hex filename 5392024 346692 121276 5859992 596a98 vmlinux.omap1_defconfig 7342851 694332 5613708 13650891 d04bcb vmlinux.omap2plus_defconfig.orig 7342623 694292 5613708 13650623 d04abf vmlinux.omap2plus_defconfig Paul Walmsley (6): OMAPDSS: remove unnecessary plat/clock.h includes staging: tidspbridge: remove unnecessary include of plat/clock.h cpufreq: OMAP: remove unnecessary include of plat/clock.h ARM: OMAP: duplicate plat-omap/clock.c into mach-omap[12]/clock.c ARM: OMAP: remove plat/clock.h ARM: OMAP: clock: split plat/clkdev_omap.h into OMAP1/2 files arch/arm/mach-omap1/board-nokia770.c |2 arch/arm/mach-omap1/clock.c| 502 ++ arch/arm/mach-omap1/clock.h| 178 +++ arch/arm/mach-omap1/clock_data.c | 13 arch/arm/mach-omap1/opp_data.c |2 arch/arm/mach-omap1/pm.c |2 arch/arm/mach-omap2/clkt2xxx_apll.c|2 arch/arm/mach-omap2/clkt2xxx_dpll.c|2 arch/arm/mach-omap2/clkt2xxx_dpllcore.c|2 arch/arm/mach-omap2/clkt2xxx_osc.c |2 arch/arm/mach-omap2/clkt2xxx_sys.c |2 arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c |2 arch/arm/mach-omap2/clkt34xx_dpll3m2.c |2 arch/arm/mach-omap2/clkt_clksel.c |2 arch/arm/mach-omap2/clkt_dpll.c|2 arch/arm/mach-omap2/clkt_iclk.c|2 arch/arm/mach-omap2/clock.c| 519 +++ arch/arm/mach-omap2/clock.h| 317 arch/arm/mach-omap2/clock2420_data.c |4 arch/arm/mach-omap2/clock2430.c|2 arch/arm/mach-omap2/clock2430_data.c |4 arch/arm/mach-omap2/clock2xxx.c|2 arch/arm/mach-omap2/clock33xx_data.c |3 arch/arm/mach-omap2/clock34xx.c|2 arch/arm/mach-omap2/clock3517.c|2 arch/arm/mach-omap2/clock36xx.c|2 arch/arm/mach-omap2/clock3xxx.c|2 arch/arm/mach-omap2/clock3xxx_data.c |4 arch/arm/mach-omap2/clock44xx_data.c |4 arch/arm/mach-omap2/clockdomain.c |2 arch/arm/mach-omap2/clockdomain.h |2 arch/arm/mach-omap2/common.c |2 arch/arm/mach-omap2/dpll3xxx.c |2 arch/arm/mach-omap2/dpll44xx.c |2 arch/arm/mach-omap2/omap_hwmod.c |2 arch/arm/mach-omap2/pm-debug.c |2 arch/arm/mach-omap2/pm24xx.c |2 arch/arm/mach-omap2/sdram-nokia.c |2 arch/arm/mach-omap2/sdrc.c |2 arch/arm/mach-omap2/sdrc2xxx.c |2 arch/arm/plat-omap/Makefile|2 arch/arm/plat-omap/clock.c | 544 arch/arm/plat-omap/counter_32k.c |1 arch/arm/plat-omap/include/plat/clock.h| 309 --- arch/arm/plat-omap/omap_device.c |1 drivers/cpufreq/omap-cpufreq.c |1 .../tidspbridge/include/dspbridge/host_os.h|1 drivers/video/omap2/dss/dispc.c|1 drivers/video/omap2/dss/dsi.c |1 drivers/video/omap2/dss/dss.c |1 50 files changed, 1536 insertions(+), 934 deletions(-) delete mode 100644 arch/arm/plat-omap/clock.c delete mode 100644 arch/arm/plat-omap/include/plat/clock.h -- 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 1/6] OMAPDSS: remove unnecessary plat/clock.h includes
The OMAP DSS video drivers include plat/clock.h but don't use any information from that file. These includes are causing problems with ARM single image kernels - remove them. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/dss/dispc.c |1 - drivers/video/omap2/dss/dsi.c |1 - drivers/video/omap2/dss/dss.c |1 - 3 files changed, 3 deletions(-) diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c index ee9e296..17fcb94 100644 --- a/drivers/video/omap2/dss/dispc.c +++ b/drivers/video/omap2/dss/dispc.c @@ -38,7 +38,6 @@ #include linux/pm_runtime.h #include plat/cpu.h -#include plat/clock.h #include video/omapdss.h diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c index b07e886..bf7a080 100644 --- a/drivers/video/omap2/dss/dsi.c +++ b/drivers/video/omap2/dss/dsi.c @@ -41,7 +41,6 @@ #include video/omapdss.h #include video/mipi_display.h -#include plat/clock.h #include dss.h #include dss_features.h diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c index 04b4586..1dfef0e 100644 --- a/drivers/video/omap2/dss/dss.c +++ b/drivers/video/omap2/dss/dss.c @@ -35,7 +35,6 @@ #include video/omapdss.h #include plat/cpu.h -#include plat/clock.h #include dss.h #include dss_features.h -- 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 4/6] ARM: OMAP: duplicate plat-omap/clock.c into mach-omap[12]/clock.c
Duplicate arch/arm/plat-omap/clock.c into arch/arm/mach-omap1/clock.c
and arch/arm/mach-omap2/clock.c. This is to support people who are working
on the ARM single image kernel and the OMAP common clock framework
conversion.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/clock.c | 499 +++
arch/arm/mach-omap1/clock_data.c | 10 -
arch/arm/mach-omap2/clock.c | 517
arch/arm/mach-omap2/clock2420_data.c |2
arch/arm/mach-omap2/clock2430_data.c |2
arch/arm/mach-omap2/clock33xx_data.c |2
arch/arm/mach-omap2/clock3xxx_data.c |2
arch/arm/mach-omap2/clock44xx_data.c |2
arch/arm/plat-omap/Makefile |2
arch/arm/plat-omap/clock.c | 544 --
10 files changed, 1010 insertions(+), 572 deletions(-)
delete mode 100644 arch/arm/plat-omap/clock.c
diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c
index 638f407..76c3f13 100644
--- a/arch/arm/mach-omap1/clock.c
+++ b/arch/arm/mach-omap1/clock.c
@@ -12,6 +12,7 @@
* published by the Free Software Foundation.
*/
#include linux/kernel.h
+#include linux/export.h
#include linux/list.h
#include linux/errno.h
#include linux/err.h
@@ -36,6 +37,10 @@
__u32 arm_idlect1_mask;
struct clk *api_ck_p, *ck_dpll1_p, *ck_ref_p;
+static LIST_HEAD(clocks);
+static DEFINE_MUTEX(clocks_mutex);
+static DEFINE_SPINLOCK(clockfw_lock);
+
/*
* Omap1 specific clock functions
*/
@@ -607,3 +612,497 @@ void omap1_clk_disable_unused(struct clk *clk)
}
#endif
+
+
+int clk_enable(struct clk *clk)
+{
+ unsigned long flags;
+ int ret;
+
+ if (clk == NULL || IS_ERR(clk))
+ return -EINVAL;
+
+ spin_lock_irqsave(clockfw_lock, flags);
+ ret = omap1_clk_enable(clk);
+ spin_unlock_irqrestore(clockfw_lock, flags);
+
+ return ret;
+}
+EXPORT_SYMBOL(clk_enable);
+
+void clk_disable(struct clk *clk)
+{
+ unsigned long flags;
+
+ if (clk == NULL || IS_ERR(clk))
+ return;
+
+ spin_lock_irqsave(clockfw_lock, flags);
+ if (clk-usecount == 0) {
+ pr_err(Trying disable clock %s with 0 usecount\n,
+ clk-name);
+ WARN_ON(1);
+ goto out;
+ }
+
+ omap1_clk_disable(clk);
+
+out:
+ spin_unlock_irqrestore(clockfw_lock, flags);
+}
+EXPORT_SYMBOL(clk_disable);
+
+unsigned long clk_get_rate(struct clk *clk)
+{
+ unsigned long flags;
+ unsigned long ret;
+
+ if (clk == NULL || IS_ERR(clk))
+ return 0;
+
+ spin_lock_irqsave(clockfw_lock, flags);
+ ret = clk-rate;
+ spin_unlock_irqrestore(clockfw_lock, flags);
+
+ return ret;
+}
+EXPORT_SYMBOL(clk_get_rate);
+
+/*
+ * Optional clock functions defined in include/linux/clk.h
+ */
+
+long clk_round_rate(struct clk *clk, unsigned long rate)
+{
+ unsigned long flags;
+ long ret;
+
+ if (clk == NULL || IS_ERR(clk))
+ return 0;
+
+ spin_lock_irqsave(clockfw_lock, flags);
+ ret = omap1_clk_round_rate(clk, rate);
+ spin_unlock_irqrestore(clockfw_lock, flags);
+
+ return ret;
+}
+EXPORT_SYMBOL(clk_round_rate);
+
+int clk_set_rate(struct clk *clk, unsigned long rate)
+{
+ unsigned long flags;
+ int ret = -EINVAL;
+
+ if (clk == NULL || IS_ERR(clk))
+ return ret;
+
+ spin_lock_irqsave(clockfw_lock, flags);
+ ret = omap1_clk_set_rate(clk, rate);
+ if (ret == 0)
+ propagate_rate(clk);
+ spin_unlock_irqrestore(clockfw_lock, flags);
+
+ return ret;
+}
+EXPORT_SYMBOL(clk_set_rate);
+
+int clk_set_parent(struct clk *clk, struct clk *parent)
+{
+ WARN_ONCE(1, clk_set_parent() not implemented for OMAP1\n);
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL(clk_set_parent);
+
+struct clk *clk_get_parent(struct clk *clk)
+{
+ return clk-parent;
+}
+EXPORT_SYMBOL(clk_get_parent);
+
+/*
+ * OMAP specific clock functions shared between omap1 and omap2
+ */
+
+int __initdata mpurate;
+
+/*
+ * By default we use the rate set by the bootloader.
+ * You can override this with mpurate= cmdline option.
+ */
+static int __init omap_clk_setup(char *str)
+{
+ get_option(str, mpurate);
+
+ if (!mpurate)
+ return 1;
+
+ if (mpurate 1000)
+ mpurate *= 100;
+
+ return 1;
+}
+__setup(mpurate=, omap_clk_setup);
+
+/* Used for clocks that always have same value as the parent clock */
+unsigned long followparent_recalc(struct clk *clk)
+{
+ return clk-parent-rate;
+}
+
+/*
+ * Used for clocks that have the same value as the parent clock,
+ * divided by some factor
+ */
+unsigned long omap_fixed_divisor_recalc(struct clk *clk)
+{
+ WARN_ON(!clk-fixed_div);
+
+ return clk-parent-rate / clk-fixed_div;
+}
+
+void clk_reparent(struct
[PATCH 3/6] cpufreq: OMAP: remove unnecessary include of plat/clock.h
Remove an unnecessary include of arch/arm/plat-omap/include/plat/clock.h to facilitate the ARM single kernel image work. Signed-off-by: Paul Walmsley p...@pwsan.com --- drivers/cpufreq/omap-cpufreq.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c index b47034e..1c9eff6 100644 --- a/drivers/cpufreq/omap-cpufreq.c +++ b/drivers/cpufreq/omap-cpufreq.c @@ -30,7 +30,6 @@ #include asm/smp_plat.h #include asm/cpu.h -#include plat/clock.h #include plat/omap-pm.h #include plat/common.h #include plat/omap_device.h -- 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 2/6] staging: tidspbridge: remove unnecessary include of plat/clock.h
The DSPBridge driver includes arch/arm/plat-omap/include/plat/clock.h. All of the plat/ ... includes are causing problems with the ARM single image kernel effort. Remove this one. Signed-off-by: Paul Walmsley p...@pwsan.com --- .../tidspbridge/include/dspbridge/host_os.h|1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/tidspbridge/include/dspbridge/host_os.h b/drivers/staging/tidspbridge/include/dspbridge/host_os.h index ed00d3d..896f157 100644 --- a/drivers/staging/tidspbridge/include/dspbridge/host_os.h +++ b/drivers/staging/tidspbridge/include/dspbridge/host_os.h @@ -40,7 +40,6 @@ #include linux/vmalloc.h #include linux/ioport.h #include linux/platform_device.h -#include plat/clock.h #include linux/clk.h #include plat/mailbox.h #include linux/pagemap.h -- 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 6/6] ARM: OMAP: clock: split plat/clkdev_omap.h into OMAP1/2 files
To facilitate the ARM single image work, split
arch/arm/plat-omap/include/plat/clkdev_omap.h into the
arch/arm/mach-omap1/clock.h and arch/arm/mach-omap2/clock.h files.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap1/clock.c |1 -
arch/arm/mach-omap1/clock.h | 25 +
arch/arm/mach-omap1/clock_data.c |1 -
arch/arm/mach-omap1/opp_data.c |2 +-
arch/arm/mach-omap2/clock.h | 33 +
arch/arm/mach-omap2/clock2420_data.c |2 --
arch/arm/mach-omap2/clock2430_data.c |2 --
arch/arm/mach-omap2/clock33xx_data.c |1 -
arch/arm/mach-omap2/clock3xxx_data.c |2 --
arch/arm/mach-omap2/clock44xx_data.c |2 --
10 files changed, 59 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c
index 847b38a..dd568d8 100644
--- a/arch/arm/mach-omap1/clock.c
+++ b/arch/arm/mach-omap1/clock.c
@@ -26,7 +26,6 @@
#include plat/usb.h
#include clock.h
#include plat/sram.h
-#include plat/clkdev_omap.h
#include mach/hardware.h
diff --git a/arch/arm/mach-omap1/clock.h b/arch/arm/mach-omap1/clock.h
index 155ddd9..1e4918a 100644
--- a/arch/arm/mach-omap1/clock.h
+++ b/arch/arm/mach-omap1/clock.h
@@ -16,9 +16,34 @@
#include linux/clk.h
#include linux/list.h
+#include linux/clkdev.h
+
struct module;
struct clk;
+struct omap_clk {
+ u16 cpu;
+ struct clk_lookup lk;
+};
+
+#define CLK(dev, con, ck, cp) \
+ { \
+.cpu = cp, \
+ .lk = { \
+ .dev_id = dev, \
+ .con_id = con, \
+ .clk = ck, \
+ }, \
+ }
+
+/* Platform flags for the clkdev-OMAP integration code */
+#define CK_310 (1 0)
+#define CK_7XX (1 1)/* 7xx, 850 */
+#define CK_1510(1 2)
+#define CK_16XX(1 3)/* 16xx, 17xx, 5912 */
+#define CK_1710(1 4)/* 1710 extra for rate
selection */
+
+
/* Temporary, needed during the common clock framework conversion */
#define __clk_get_name(clk)(clk-name)
#define __clk_get_parent(clk) (clk-parent)
diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index 9c376f5..3c3590e 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -24,7 +24,6 @@
#include clock.h
#include plat/cpu.h
-#include plat/clkdev_omap.h
#include plat/sram.h /* for omap_sram_reprogram_clock() */
#include mach/hardware.h
diff --git a/arch/arm/mach-omap1/opp_data.c b/arch/arm/mach-omap1/opp_data.c
index 9cd4ddb..8dcebe6 100644
--- a/arch/arm/mach-omap1/opp_data.c
+++ b/arch/arm/mach-omap1/opp_data.c
@@ -10,7 +10,7 @@
* published by the Free Software Foundation.
*/
-#include plat/clkdev_omap.h
+#include clock.h
#include opp.h
/*-
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index c3bf8c2..cfba1ff 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -19,6 +19,39 @@
#include linux/kernel.h
#include linux/list.h
+#include linux/clkdev.h
+
+struct omap_clk {
+ u16 cpu;
+ struct clk_lookup lk;
+};
+
+#define CLK(dev, con, ck, cp) \
+ { \
+.cpu = cp, \
+ .lk = { \
+ .dev_id = dev, \
+ .con_id = con, \
+ .clk = ck, \
+ }, \
+ }
+
+/* Platform flags for the clkdev-OMAP integration code */
+#define CK_242X(1 0)
+#define CK_243X(1 1)/* 243x, 253x */
+#define CK_3430ES1 (1 2)/* 34xxES1 only */
+#define CK_3430ES2PLUS (1 3)/* 34xxES2, ES3, non-Sitara 35xx only */
+#define CK_AM35XX (1 4)/* Sitara AM35xx */
+#define CK_36XX(1 5)/* 36xx/37xx-specific clocks */
+#define CK_443X(1 6)
+#define CK_TI816X (1 7)
+#define CK_446X(1 8)
+#define CK_AM33XX (1 9)/* AM33xx specific clocks */
+
+
+#define CK_34XX(CK_3430ES1 | CK_3430ES2PLUS)
+#define CK_3XXX(CK_34XX | CK_AM35XX | CK_36XX)
+
struct module;
struct clk;
struct clockdomain;
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index 5be7405f..ff47a6c 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -18,8 +18,6 @@
#include linux/clk.h
#include linux/list.h
-#include plat/clkdev_omap.h
-
#include soc.h
#include iomap.h
#include clock.h
diff
[PATCH 5/6] ARM: OMAP: remove plat/clock.h
Remove arch/arm/plat-omap/include/plat/clock.h by merging it into
arch/arm/mach-omap1/clock.h and arch/arm/mach-omap2/clock.h.
The goal here is to facilitate ARM single image kernels by removing
includes via the plat/ symlink.
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap1/board-nokia770.c |2
arch/arm/mach-omap1/clock.c |2
arch/arm/mach-omap1/clock.h | 153 +
arch/arm/mach-omap1/clock_data.c |2
arch/arm/mach-omap1/pm.c |2
arch/arm/mach-omap2/clkt2xxx_apll.c |2
arch/arm/mach-omap2/clkt2xxx_dpll.c |2
arch/arm/mach-omap2/clkt2xxx_dpllcore.c |2
arch/arm/mach-omap2/clkt2xxx_osc.c |2
arch/arm/mach-omap2/clkt2xxx_sys.c |2
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c |2
arch/arm/mach-omap2/clkt34xx_dpll3m2.c |2
arch/arm/mach-omap2/clkt_clksel.c|2
arch/arm/mach-omap2/clkt_dpll.c |2
arch/arm/mach-omap2/clkt_iclk.c |2
arch/arm/mach-omap2/clock.c |2
arch/arm/mach-omap2/clock.h | 284
arch/arm/mach-omap2/clock2430.c |2
arch/arm/mach-omap2/clock2xxx.c |2
arch/arm/mach-omap2/clock34xx.c |2
arch/arm/mach-omap2/clock3517.c |2
arch/arm/mach-omap2/clock36xx.c |2
arch/arm/mach-omap2/clock3xxx.c |2
arch/arm/mach-omap2/clockdomain.c|2
arch/arm/mach-omap2/clockdomain.h|2
arch/arm/mach-omap2/common.c |2
arch/arm/mach-omap2/dpll3xxx.c |2
arch/arm/mach-omap2/dpll44xx.c |2
arch/arm/mach-omap2/omap_hwmod.c |2
arch/arm/mach-omap2/pm-debug.c |2
arch/arm/mach-omap2/pm24xx.c |2
arch/arm/mach-omap2/sdram-nokia.c|2
arch/arm/mach-omap2/sdrc.c |2
arch/arm/mach-omap2/sdrc2xxx.c |2
arch/arm/plat-omap/counter_32k.c |1
arch/arm/plat-omap/include/plat/clock.h | 309 --
arch/arm/plat-omap/omap_device.c |1
37 files changed, 467 insertions(+), 345 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/clock.h
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index ec01f03..fef0a93 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -29,7 +29,7 @@
#include plat/keypad.h
#include plat/lcd_mipid.h
#include plat/mmc.h
-#include plat/clock.h
+#include clock.h
#include mach/hardware.h
#include mach/usb.h
diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c
index 76c3f13..847b38a 100644
--- a/arch/arm/mach-omap1/clock.c
+++ b/arch/arm/mach-omap1/clock.c
@@ -24,7 +24,7 @@
#include plat/cpu.h
#include plat/usb.h
-#include plat/clock.h
+#include clock.h
#include plat/sram.h
#include plat/clkdev_omap.h
diff --git a/arch/arm/mach-omap1/clock.h b/arch/arm/mach-omap1/clock.h
index 3d04f4f..155ddd9 100644
--- a/arch/arm/mach-omap1/clock.h
+++ b/arch/arm/mach-omap1/clock.h
@@ -14,8 +14,159 @@
#define __ARCH_ARM_MACH_OMAP1_CLOCK_H
#include linux/clk.h
+#include linux/list.h
-#include plat/clock.h
+struct module;
+struct clk;
+
+/* Temporary, needed during the common clock framework conversion */
+#define __clk_get_name(clk)(clk-name)
+#define __clk_get_parent(clk) (clk-parent)
+#define __clk_get_rate(clk)(clk-rate)
+
+/**
+ * struct clkops - some clock function pointers
+ * @enable: fn ptr that enables the current clock in hardware
+ * @disable: fn ptr that enables the current clock in hardware
+ * @find_idlest: function returning the IDLEST register for the clock's IP blk
+ * @find_companion: function returning the companion clk reg for the clock
+ * @allow_idle: fn ptr that enables autoidle for the current clock in hardware
+ * @deny_idle: fn ptr that disables autoidle for the current clock in hardware
+ *
+ * A companion clk is an accompanying clock to the one being queried
+ * that must be enabled for the IP module connected to the clock to
+ * become accessible by the hardware. Neither @find_idlest nor
+ * @find_companion should be needed; that information is IP
+ * block-specific; the hwmod code has been created to handle this, but
+ * until hwmod data is ready and drivers have been converted to use PM
+ * runtime calls in place of clk_enable()/clk_disable(), @find_idlest and
+ * @find_companion must, unfortunately, remain.
+ */
+struct clkops {
+ int (*enable)(struct clk *);
+ void(*disable)(struct clk *);
+ void(*find_idlest)(struct clk *, void __iomem **,
+ u8
Which git to clone for testing prior to submitting bugs?
Hello, We're developing a system based on DM3730, and using Beagleboard-xM as a prototype platform. The 3.2 series kernels provided a working video output on Beagleboard-xM integrated HDMI connector. We use the kernel parameters: omapfb.mode=dvi:800x480MR-24@60 omapfb.vram=0:6M,1:2M,2:2M omapdss.def_disp=dvi We upgraded to kernel 3.4.3 in order to take advantage of the kernel parameter: buddy=spidev This provided spidev access without requiring that we build a custom kernel. However in the 3.4 series, dvi output no longer works. In a subsequent distro upgrade to 3.4.4 neither dvi, nor buddy=spidev function anymore. I'd like to test the latest appropriate kernel prior to considering these issues as current bugs. Can someone please advise which git tree to clone, for testing and possible bisect, prior to reporting bugs to this list? Thank You John Andrews li...@johnea.net -- 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: Which git to clone for testing prior to submitting bugs?
On Thu, Sep 27, 2012 at 12:19 PM, li...@johnea.net wrote: Hello, We're developing a system based on DM3730, and using Beagleboard-xM as a prototype platform. The 3.2 series kernels provided a working video output on Beagleboard-xM integrated HDMI connector. We use the kernel parameters: omapfb.mode=dvi:800x480MR-24@60 omapfb.vram=0:6M,1:2M,2:2M omapdss.def_disp=dvi We upgraded to kernel 3.4.3 in order to take advantage of the kernel parameter: buddy=spidev This provided spidev access without requiring that we build a custom kernel. However in the 3.4 series, dvi output no longer works. In a subsequent distro upgrade to 3.4.4 neither dvi, nor buddy=spidev function anymore. buddy=xyz is not upstream, so which 'tree'/'patchset' are you currently using as a basis for your device? The authors of that patchset might be able to help out.. I'd like to test the latest appropriate kernel prior to considering these issues as current bugs. Can someone please advise which git tree to clone, for testing and possible bisect, prior to reporting bugs to this list? Regards, -- Robert Nelson http://www.rcn-ee.com/ -- 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: Powering OMAP's pins
* Tomi Valkeinen tomi.valkei...@ti.com [120927 00:20]: On Wed, 2012-09-26 at 11:59 -0700, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [120926 00:06]: So if I want to use parallel dss output, which uses dss_data0 pin, omapdss driver needs to enable vdda_dsi on omap3430, even though there's no other use for vdda_dsi in the parallel output case. But on omap4430 data0 pins seems to be powered by vdds_1p8v. On AM35xx something else. So either I need to program all those into the omapdss driver, which is not the right way as they are platform specific things, or I need to pass some kind of pin data from platform data to omapdss driver, giving the required regulator for each pin. Pass the device tree regulators to the DSS driver and enable the ones with runtime PM in the DSS driver? I guess you have the names for those regulatros? Well, yes, I could create a pin-regulator mapping for dss that is filled in the DT data. OK, that's probably the way to go as we don't have any other place for that mapping. I just feel this is something that the omapdss driver shouldn't care about. The powers for the pins are in no way related to dss. OK, maybe some of this can be done automatically later. And how about the uart1_cts or gpio_70 pins on 3430? Do both uart and gpio drivers need to have similar kind of platform data, giving the required regulator so that the pin can be enabled? Hmm aren't those always enabled with VIO_18? No, 3430 datamanual (OMAP34xx_ES2.0_ES2.1_POP_DM_V_K.pdf) says some uart and gpio pins are powered by vdds_dsi, some by vdds_sdi, some gpio pins are powered by vdds_csi2, etc. OK. I guess these pins are rarely used in the alternative mux modes as it has not been much of a problem so far. I could be mistaken how to HW works (but it does work like that for dss), but sounds to me that uart and gpio drivers (and perhaps some others, I didn't go through all the pins) need similar pin-regulator mapping as you suggested for omapdss. Yes it seems that there are supply voltage regulator domains that are specific to some subsystems. I wonder if these are needed in all mux modes, or only when the pins are muxed for that particular subsystem? It could be that the documentation is missing some information here.. For example, what happens if you try to use some vdds_dsi powered pin in GPIO mode without vdds_dsi? Regards, Tony -- 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: Powering OMAP's pins
* Tony Lindgren t...@atomide.com [120927 11:45]: * Tomi Valkeinen tomi.valkei...@ti.com [120927 00:20]: I could be mistaken how to HW works (but it does work like that for dss), but sounds to me that uart and gpio drivers (and perhaps some others, I didn't go through all the pins) need similar pin-regulator mapping as you suggested for omapdss. Yes it seems that there are supply voltage regulator domains that are specific to some subsystems. I wonder if these are needed in all mux modes, or only when the pins are muxed for that particular subsystem? It could be that the documentation is missing some information here.. For example, what happens if you try to use some vdds_dsi powered pin in GPIO mode without vdds_dsi? Seems like this may provide some clues from 3.6 Power-up and Power-down: If the SDI, DSI, or CSI2 and CSIb interfaces are used in standard LVCMOS mode (that is, GPIO mode) rather than PHY mode (that is, serial differential mode), then vdds_sdi, vdds_dsi, vdds_csi2, and vdds_csib may also be connected to vdds. Please, see the recommended SDI, DSI, CSI2, and CSIb power supply noise of Table 3-5, Recommended Operating Conditions. So based on that it seems that tweaking of the regulators for these pins is only needed for DSS etc, not for GPIO or serial usage. Regards, Tony -- 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: Which git to clone for testing prior to submitting bugs?
On 09/27/2012 11:25 AM, Robert Nelson wrote: On Thu, Sep 27, 2012 at 12:19 PM,li...@johnea.net wrote: Hello, In a subsequent distro upgrade to 3.4.4 neither dvi, nor buddy=spidev function anymore. buddy=xyz is not upstream, so which 'tree'/'patchset' are you currently using as a basis for your device? The authors of that patchset might be able to help out.. Thanks Robert, The 3.4.4 kernel is plain vanilla plus: http://rcn-ee.net/deb/sid-armhf/v3.4.4-x1/patch-3.4.4-x1.diff.gz We're running archlinuxarm, and working with devs there to upgrade to 3.5.4, in hopes this will address most or all of the issues. That will include: http://rcn-ee.net/deb/sid-armhf/v3.5.4-x6/patch-3.5.4-x6.diff.gz We adopted archlinux because it's about as close to a git kernel as can be had in a disto packaged format. If we still experience issues, I'm trying to understand what to clone to be relevant to this list. Which tree are patches submitted against here? Thanks again! johnea -- 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: Which git to clone for testing prior to submitting bugs?
Hi, On Thu, Sep 27, 2012 at 11:56:51AM -0700, li...@johnea.net wrote: On 09/27/2012 11:25 AM, Robert Nelson wrote: On Thu, Sep 27, 2012 at 12:19 PM,li...@johnea.net wrote: Hello, In a subsequent distro upgrade to 3.4.4 neither dvi, nor buddy=spidev function anymore. buddy=xyz is not upstream, so which 'tree'/'patchset' are you currently using as a basis for your device? The authors of that patchset might be able to help out.. Thanks Robert, The 3.4.4 kernel is plain vanilla plus: http://rcn-ee.net/deb/sid-armhf/v3.4.4-x1/patch-3.4.4-x1.diff.gz We're running archlinuxarm, and working with devs there to upgrade to 3.5.4, in hopes this will address most or all of the issues. That will include: http://rcn-ee.net/deb/sid-armhf/v3.5.4-x6/patch-3.5.4-x6.diff.gz We adopted archlinux because it's about as close to a git kernel as can be had in a disto packaged format. If we still experience issues, I'm trying to understand what to clone to be relevant to this list. Which tree are patches submitted against here? If you want to try with the public kernel, then try Linus' tree (http://git.kernel.org/linus) but I'm not sure if we have beagle XM in mainline yet. Tony is DM3730 supported in mainline ? -- balbi signature.asc Description: Digital signature
Re: Which git to clone for testing prior to submitting bugs?
* Felipe Balbi ba...@ti.com [120927 12:01]: If you want to try with the public kernel, then try Linus' tree (http://git.kernel.org/linus) but I'm not sure if we have beagle XM in mainline yet. Yes Tony is DM3730 supported in mainline ? Yes Tony -- 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 3/3] arm: omap: Move iommu/iovmm headers to platform_data
Em Fri, 21 Sep 2012 01:14:08 -0400
Ido Yariv i...@wizery.com escreveu:
Move iommu/iovmm headers from plat/ to platform_data/ as part of the
single zImage work.
Signed-off-by: Ido Yariv i...@wizery.com
---
arch/arm/mach-omap2/devices.c | 2 +-
arch/arm/mach-omap2/iommu2.c| 2 +-
arch/arm/mach-omap2/omap-iommu.c| 2 +-
drivers/iommu/omap-iommu-debug.c| 4 ++--
drivers/iommu/omap-iommu.c | 2 +-
drivers/iommu/omap-iovmm.c | 4 ++--
drivers/media/platform/omap3isp/isp.h | 5 +++--
drivers/media/platform/omap3isp/ispvideo.c | 6
--
Acked-by: Mauro Carvalho Chehab mche...@redhat.com
.../plat/iommu.h = include/linux/platform_data/iommu-omap.h| 0
.../plat/iovmm.h = include/linux/platform_data/iovmm-omap.h| 0
10 files changed, 15 insertions(+), 12 deletions(-)
rename arch/arm/plat-omap/include/plat/iommu.h =
include/linux/platform_data/iommu-omap.h (100%)
rename arch/arm/plat-omap/include/plat/iovmm.h =
include/linux/platform_data/iovmm-omap.h (100%)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1bb2e92..5bde5c2 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -126,7 +126,7 @@ static struct platform_device omap2cam_device = {
#if defined(CONFIG_IOMMU_API)
-#include plat/iommu.h
+#include linux/platform_data/iommu-omap.h
static struct resource omap3isp_resources[] = {
{
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index eefc379..cab7acc 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -18,7 +18,7 @@
#include linux/slab.h
#include linux/stringify.h
-#include plat/iommu.h
+#include linux/platform_data/iommu-omap.h
/*
* omap2 architecture specific register bit definitions
diff --git a/arch/arm/mach-omap2/omap-iommu.c
b/arch/arm/mach-omap2/omap-iommu.c
index df298d4..a6a4ff8 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -13,7 +13,7 @@
#include linux/module.h
#include linux/platform_device.h
-#include plat/iommu.h
+#include linux/platform_data/iommu-omap.h
#include soc.h
#include common.h
diff --git a/drivers/iommu/omap-iommu-debug.c
b/drivers/iommu/omap-iommu-debug.c
index f55fc5d..e6ee7c2 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -19,8 +19,8 @@
#include linux/platform_device.h
#include linux/debugfs.h
-#include plat/iommu.h
-#include plat/iovmm.h
+#include linux/platform_data/iommu-omap.h
+#include linux/platform_data/iovmm-omap.h
#include plat/iopgtable.h
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index d0b1234..298ca19 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -24,7 +24,7 @@
#include asm/cacheflush.h
-#include plat/iommu.h
+#include linux/platform_data/iommu-omap.h
#include plat/iopgtable.h
diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c
index 2e10c3e..ade7c6c 100644
--- a/drivers/iommu/omap-iovmm.c
+++ b/drivers/iommu/omap-iovmm.c
@@ -21,8 +21,8 @@
#include asm/cacheflush.h
#include asm/mach/map.h
-#include plat/iommu.h
-#include plat/iovmm.h
+#include linux/platform_data/iommu-omap.h
+#include linux/platform_data/iovmm-omap.h
#include plat/iopgtable.h
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h
index 8be7487..62c76f9 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -34,8 +34,9 @@
#include linux/platform_device.h
#include linux/wait.h
#include linux/iommu.h
-#include plat/iommu.h
-#include plat/iovmm.h
+
+#include linux/platform_data/iommu-omap.h
+#include linux/platform_data/iovmm-omap.h
#include ispstat.h
#include ispccdc.h
diff --git a/drivers/media/platform/omap3isp/ispvideo.c
b/drivers/media/platform/omap3isp/ispvideo.c
index 3a5085e..1093f07 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -34,8 +34,10 @@
#include linux/vmalloc.h
#include media/v4l2-dev.h
#include media/v4l2-ioctl.h
-#include plat/iommu.h
-#include plat/iovmm.h
+
+#include linux/platform_data/iommu-omap.h
+#include linux/platform_data/iovmm-omap.h
+
#include plat/omap-pm.h
#include ispvideo.h
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/include/linux/platform_data/iommu-omap.h
similarity index 100%
rename from arch/arm/plat-omap/include/plat/iommu.h
rename to include/linux/platform_data/iommu-omap.h
diff --git a/arch/arm/plat-omap/include/plat/iovmm.h
Re: Which git to clone for testing prior to submitting bugs?
On Thu, Sep 27, 2012 at 1:56 PM, li...@johnea.net wrote: On 09/27/2012 11:25 AM, Robert Nelson wrote: On Thu, Sep 27, 2012 at 12:19 PM,li...@johnea.net wrote: Hello, In a subsequent distro upgrade to 3.4.4 neither dvi, nor buddy=spidev function anymore. buddy=xyz is not upstream, so which 'tree'/'patchset' are you currently using as a basis for your device? The authors of that patchset might be able to help out.. Thanks Robert, The 3.4.4 kernel is plain vanilla plus: http://rcn-ee.net/deb/sid-armhf/v3.4.4-x1/patch-3.4.4-x1.diff.gz We're running archlinuxarm, and working with devs there to upgrade to 3.5.4, in hopes this will address most or all of the issues. That will include: http://rcn-ee.net/deb/sid-armhf/v3.5.4-x6/patch-3.5.4-x6.diff.gz We adopted archlinux because it's about as close to a git kernel as can be had in a disto packaged format. Ah, so my external patchset... Well, for the patch, nothing actually changed between 3.4.3-x1 - 3.4.4-x1... (besides the stable patchset) https://github.com/RobertCNelson/stable-kernel/commits/v3.4.x/ (the 3 commits are related to scripts in that git repo.) So, i would first look at the config (zcat /proc/config.gz) between those two releases, and if the arch developers added any more patches to it.. Looking at the 3.4.4 commit log http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=shortlog;h=refs/heads/linux-3.4.y;pg=5 No omapdss changes... If we still experience issues, I'm trying to understand what to clone to be relevant to this list. Which tree are patches submitted against here? If it's for arm/omap side tony's tree: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=summary For the display: http://gitorious.org/linux-omap-dss2/linux But everything is now based on mainline.. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- 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: Which git to clone for testing prior to submitting bugs?
Thanks Robert, The 3.4.4 kernel is plain vanilla plus: http://rcn-ee.net/deb/sid-armhf/v3.4.4-x1/patch-3.4.4-x1.diff.gz We're running archlinuxarm, and working with devs there to upgrade to 3.5.4, in hopes this will address most or all of the issues. That will include: http://rcn-ee.net/deb/sid-armhf/v3.5.4-x6/patch-3.5.4-x6.diff.gz We adopted archlinux because it's about as close to a git kernel as can be had in a disto packaged format. Ah, so my external patchset... Well, for the patch, nothing actually changed between 3.4.3-x1 - 3.4.4-x1... (besides the stable patchset) https://github.com/RobertCNelson/stable-kernel/commits/v3.4.x/ (the 3 commits are related to scripts in that git repo.) So, i would first look at the config (zcat /proc/config.gz) between those two releases, and if the arch developers added any more patches to it.. https://github.com/archlinuxarm/PKGBUILDs/commit/68a9e5a1609fde10a2f31dac8df211f0c3874eb7 It looks like they disabled CONFIG_OMAP_RESET_CLOCKS I'm pretty sure that would force you to be stuck with what ever u-boot sets up for those pins... Regards, -- Robert Nelson http://www.rcn-ee.com/ -- 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 2/3] iommu/omap: Merge iommu2.h into iommu.h
Hi Ido, * Ido Yariv i...@wizery.com [120920 22:15]: Since iommu is not currently supported on OMAP1, merge plat/iommu2.h into iommu.h so only one file would have to move to platform_data/ as part of the single zImage effort. Looks like you need patch 2.5/3 in this series too that makes some of the things defined in iommu.h local. We should only have platform data in include/linux/platform_data, so things that are private to drivers should be defined in the driver, and things that are private to arch/arm/mach-omap2 should defined locally there. Based on a quick grepping of files, looks like these should be defined in omap-iommu.c driver and not in the platform_data header: struct iotlb_lock struct iotlb_lock dev_to_omap_iommu various register defines omap_iommu_arch_version omap_iotlb_cr_to_e omap_iopgtable_store_entry omap_iommu_save_ctx omap_iommu_restore_ctx omap_foreach_iommu_device omap_iommu_dump_ctx omap_dump_tlb_entries Regards, Tony -- 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 2/3] iommu/omap: Merge iommu2.h into iommu.h
* Tony Lindgren t...@atomide.com [120927 12:54]: Hi Ido, * Ido Yariv i...@wizery.com [120920 22:15]: Since iommu is not currently supported on OMAP1, merge plat/iommu2.h into iommu.h so only one file would have to move to platform_data/ as part of the single zImage effort. Looks like you need patch 2.5/3 in this series too that makes some of the things defined in iommu.h local. We should only have platform data in include/linux/platform_data, so things that are private to drivers should be defined in the driver, and things that are private to arch/arm/mach-omap2 should defined locally there. Based on a quick grepping of files, looks like these should be defined in omap-iommu.c driver and not in the platform_data header: struct iotlb_lock struct iotlb_lock dev_to_omap_iommu various register defines omap_iommu_arch_version omap_iotlb_cr_to_e omap_iopgtable_store_entry omap_iommu_save_ctx omap_iommu_restore_ctx omap_foreach_iommu_device omap_iommu_dump_ctx omap_dump_tlb_entries And looks like while at it, you can also move plat/iopgtable.h and put it in some drivers/iommu/*.h file that's shared by omap-iommu*.c and omap-iovmm.c drivers ;) Regards, Tony -- 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 -- 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: Help needed with remaining plat headers
* Tomi Valkeinen tomi.valkei...@ti.com [120927 03:13]: On Thu, 2012-09-20 at 16:29 -0700, Tony Lindgren wrote: Hi all, With the recent pull request I sent for v3.7, we now have pretty much all the mach includes fixed up for omap2+ for single zImage support. We still have quite a few plat headers that we need to sort out manually. Please take a look at the following list, and reply to this thread if you are working on patches moving one of the headers in the list so we can coordinate things. The rules are simple vram.h vrfb.h I'll work on these ones. Thanks. Can you please also remove the remaining cpu_is_omap and soc_is_omap usage from drivers/video for omap2+ early with some patches that I can apply to my cleanup branch early? Regards, Tony -- 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: Help needed with remaining plat headers
* Vutla, Lokesh lokeshvu...@ti.com [120927 02:59]: dma-44xx.h dma.h As a part of clean up I am looking at dma.h and dma-44xx.h files ll send you patches once cleanup and testing is done. OK great that's good to hear. Tony -- 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 v2 1/2] omap3: Provide means for changing CSI2 PHY configuration
Hi Laurent, Thanks for the review! Laurent Pinchart wrote: Hi Sakari, Thanks for the patch. On Thursday 27 September 2012 00:50:35 Sakari Ailus wrote: The OMAP 3630 has configuration how the ISP CSI-2 PHY pins are connected to the actual CSI-2 receivers outside the ISP itself. Allow changing this configuration from the ISP driver. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Just one small comment below, otherwise Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- arch/arm/mach-omap2/control.c | 86 + arch/arm/mach-omap2/control.h | 15 + arch/arm/mach-omap2/include/mach/control.h | 13 3 files changed, 114 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/include/mach/control.h diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c index 3223b81..11bb900 100644 --- a/arch/arm/mach-omap2/control.c +++ b/arch/arm/mach-omap2/control.c ... + cam_phy_ctrl |= mode shift; + + omap_ctrl_writel(cam_phy_ctrl, +OMAP3630_CONTROL_CAMERA_PHY_CTRL); This can fit on one line. I'll fix that for the next version. I noticed there were a few too long lines, too; I've broken them up where it makes sense, and removed a useless break statement. Cheers, -- Sakari Ailus sakari.ai...@iki.fi -- 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: Which git to clone for testing prior to submitting bugs?
On 09/27/2012 12:39 PM, Robert Nelson wrote: So, i would first look at the config (zcat /proc/config.gz) between those two releases, and if the arch developers added any more patches to it.. https://github.com/archlinuxarm/PKGBUILDs/commit/68a9e5a1609fde10a2f31dac8df211f0c3874eb7 It looks like they disabled CONFIG_OMAP_RESET_CLOCKS I'm pretty sure that would force you to be stuck with what ever u-boot sets up for those pins... Thank you very much Robert! I found this in your 3.5 series patchset logs: beagle: video works now, had to drop the hi-speed pll divider, as the infastructure for it looks to have been removed https://github.com/RobertCNelson/stable-kernel/commit/e7c8d9e8894997ae6a1ad9c83292ed75c5ac32c5 Which makes me think 3.5.4 on the beagle with your patches will have DVI again. I just received a kernel to test from the archlinuxarm devs, if spidev is still missing, I'll pass along your advice regarding CONFIG_OMAP_RESET_CLOCKS. Thanks again for your help! I'll follow up with the results... johnea -- 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 v2 2/2] omap3isp: Configure CSI-2 phy based on platform data
Hi Laurent,
Thanks for the review.
Laurent Pinchart wrote:
On Thursday 27 September 2012 00:50:36 Sakari Ailus wrote:
Configure CSI-2 phy based on platform data in the ISP driver. For that, the
new V4L2_CID_IMAGE_SOURCE_PIXEL_RATE control is used. Previously the same
was configured from the board code.
This patch is dependent on omap3: Provide means for changing CSI2 PHY
configuration.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/omap3isp/isp.h |3 -
drivers/media/platform/omap3isp/ispcsiphy.c | 161 +---
drivers/media/platform/omap3isp/ispcsiphy.h | 10 --
3 files changed, 90 insertions(+), 84 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c
b/drivers/media/platform/omap3isp/ispcsiphy.c index 348f67e..1d16e66 100644
--- a/drivers/media/platform/omap3isp/ispcsiphy.c
+++ b/drivers/media/platform/omap3isp/ispcsiphy.c
...
@@ -162,10 +120,72 @@ static int csiphy_config(struct isp_csiphy *phy,
if (lanes-clk.pos == 0 || used_lanes (1 lanes-clk.pos))
return -EINVAL;
- mutex_lock(phy-mutex);
- phy-dphy = *dphy;
- phy-lanes = *lanes;
- mutex_unlock(phy-mutex);
+ switch (subdevs-interface) {
+ case ISP_INTERFACE_CSI2A_PHY2:
+ phy_num = OMAP3_CTRL_CSI2_PHY2_CSI2A;
+ break;
+ case ISP_INTERFACE_CSI2C_PHY1:
+ phy_num = OMAP3_CTRL_CSI2_PHY1_CSI2C;
+ break;
+ case ISP_INTERFACE_CCP2B_PHY1:
+ phy_num = OMAP3_CTRL_CSI2_PHY1_CCP2B;
+ break;
+ case ISP_INTERFACE_CCP2B_PHY2:
+ phy_num = OMAP3_CTRL_CSI2_PHY2_CCP2B;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ omap3_ctrl_csi2_phy_cfg(phy_num, true, 0);
+
+ /* DPHY timing configuration */
+ /* CSI-2 is DDR and we only count used lanes. */
+ csi2_ddrclk_khz = pipe-external_rate / 1000
+ / (2 * hweight32(used_lanes)) * pipe-external_width;
Board code previously used op_sys_clk_freq_hz / 1000 / (2 *
hweight32(used_lanes)). Looking at the SMIA++ PLL code, pipe-external_rate is
equal to op_sys_clk_freq_hz / bits_per_pixel * lane_op_clock_ratio. Both
values are identical if lane_op_clock_ratio is set to 1, which is the case if
the SMIAPP_QUIRK_FLAG_OP_PIX_CLOCK_PER_LANE quirk is not set. Have you
verified that the new CSI2 DDR clock frequency calculation is correct when the
quirk is set ?
Good point. The presence of that quirk flag means that the bit rate (or
clock) is per-lane, and not all lanes together as it should be. This is
why the value is multiplied by the number of lanes. It should have no
visibility outside the SMIA++ driver itself; if it does, then it's a bug
in the SMIA++ driver.
+ reg = isp_reg_readl(csi2-isp, csi2-phy-phy_regs, ISPCSIPHY_REG0);
Isn't csi2-phy == phy ? You could then just write
reg = isp_reg_readl(phy-isp, phy-phy_regs, ISPCSIPHY_REG0);
and similarly below.
Fixed.
Cheers,
--
Sakari Ailus
sakari.ai...@iki.fi
--
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: Help needed with remaining plat headers
Please see below a status update on the remaining problem plat headers. Note that all patches should be against current linux next in this case. * Tony Lindgren t...@atomide.com [120920 16:30]: $ ls arch/arm/plat-omap/include/plat/ clkdev_omap.h clock.h Paul posted patches for the clock headers. common.h I'll make common.h local. cpu.h Making cpu.h local requires getting rid of cpu_is_omap/soc_is_omap usage in drivers for mach-omap2+, so please fix your drivers! dma-44xx.h dma.h Lokesh will post patches for the dma*.h files. dmtimer.h Jon, can you do a patch for dmtimer.h? fpga.h I'll make fpga.h local to mach-omap1. gpmc.h Afzal, can you do a patch for gpmc.h? i2c.h Will move to platform_data after defining register functions locally. iommu2.h iommu.h iopgtable.h iovmm.h There are io*.h patches posted for these by Ido that need a bit more work to clear out the non-platform-data parts that should be local to the driver. led.h Will move to platform_data. mailbox.h Omar, can you please do a patch that makes mailbox.h suitable for include/linux/platform_data/mailbox-omap.h? menelaus.h Will convert to be suitable for include/linux/platform_data. mmc.h Will convert to be suitable for include/linux/platform_data. multi.h Will make multi.h local. omap_device.h omap_hwmod.h Will make omap_device.h and omap_hwmod.h local to mach-omap2. omap-pm.h omap-secure.h omap-serial.h Will fix up for platform_data/serial-omap.h. prcm.h sdrc.h Will make prcm.h and sdrc.h local to mach-omap2. serial.h Will fix up for platform_data/serial-omap.h. sram.h Will make sram.h local. tc.h Will make tc.h local to mach-omap1. timex.h Igor is looking into timex.h. uncompress.h We can just move and disable the DEBUG_LL unless UART address + shift are specified in Kconfig in a generic way. I think this is already possible or patches have been posted to LAKML? usb.h Felipe can you do a patch for this one? vram.h vrfb.h Tomi will post patches for vr*.h files. Regards, Tony -- 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: Help needed with remaining plat headers
Missed omap-pm.h and omap-secure.h, see below.. * Tony Lindgren t...@atomide.com [120927 13:27]: Please see below a status update on the remaining problem plat headers. Note that all patches should be against current linux next in this case. * Tony Lindgren t...@atomide.com [120920 16:30]: $ ls arch/arm/plat-omap/include/plat/ clkdev_omap.h clock.h Paul posted patches for the clock headers. common.h I'll make common.h local. cpu.h Making cpu.h local requires getting rid of cpu_is_omap/soc_is_omap usage in drivers for mach-omap2+, so please fix your drivers! dma-44xx.h dma.h Lokesh will post patches for the dma*.h files. dmtimer.h Jon, can you do a patch for dmtimer.h? fpga.h I'll make fpga.h local to mach-omap1. gpmc.h Afzal, can you do a patch for gpmc.h? i2c.h Will move to platform_data after defining register functions locally. iommu2.h iommu.h iopgtable.h iovmm.h There are io*.h patches posted for these by Ido that need a bit more work to clear out the non-platform-data parts that should be local to the driver. led.h Will move to platform_data. mailbox.h Omar, can you please do a patch that makes mailbox.h suitable for include/linux/platform_data/mailbox-omap.h? menelaus.h Will convert to be suitable for include/linux/platform_data. mmc.h Will convert to be suitable for include/linux/platform_data. multi.h Will make multi.h local. omap_device.h omap_hwmod.h Will make omap_device.h and omap_hwmod.h local to mach-omap2. omap-pm.h I think Kevin already has some patches to make this local? omap-secure.h Will make omap-secure.h local. omap-serial.h Will fix up for platform_data/serial-omap.h. prcm.h sdrc.h Will make prcm.h and sdrc.h local to mach-omap2. serial.h Will fix up for platform_data/serial-omap.h. sram.h Will make sram.h local. tc.h Will make tc.h local to mach-omap1. timex.h Igor is looking into timex.h. uncompress.h We can just move and disable the DEBUG_LL unless UART address + shift are specified in Kconfig in a generic way. I think this is already possible or patches have been posted to LAKML? usb.h Felipe can you do a patch for this one? vram.h vrfb.h Tomi will post patches for vr*.h files. Regards, Tony -- 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: Help needed with remaining plat headers
On Fri, Sep 28, 2012 at 1:56 AM, Tony Lindgren t...@atomide.com wrote: Please see below a status update on the remaining problem plat headers. Note that all patches should be against current linux next in this case. * Tony Lindgren t...@atomide.com [120920 16:30]: $ ls arch/arm/plat-omap/include/plat/ [..] omap-secure.h Will work with Lokesh to get this one sorted out along with dma. It can be made local to mach-omap2. Regards Santosh -- 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: Which git to clone for testing prior to submitting bugs?
On Thu, Sep 27, 2012 at 3:16 PM, li...@johnea.net wrote: On 09/27/2012 12:39 PM, Robert Nelson wrote: So, i would first look at the config (zcat /proc/config.gz) between those two releases, and if the arch developers added any more patches to it.. https://github.com/archlinuxarm/PKGBUILDs/commit/68a9e5a1609fde10a2f31dac8df211f0c3874eb7 It looks like they disabled CONFIG_OMAP_RESET_CLOCKS I'm pretty sure that would force you to be stuck with what ever u-boot sets up for those pins... Thank you very much Robert! I found this in your 3.5 series patchset logs: beagle: video works now, had to drop the hi-speed pll divider, as the infastructure for it looks to have been removed https://github.com/RobertCNelson/stable-kernel/commit/e7c8d9e8894997ae6a1ad9c83292ed75c5ac32c5 Which makes me think 3.5.4 on the beagle with your patches will have DVI again. Correct, dropping that specific patch (1), got 3.5.x working on my beagle again. .( i was distracted with an another project, so i was a little late in testing/stabilizing 3.5.x when porting the v3.4.x patchset ;) ..) But at the same time, that was using a nice feature (hi speed pll: .dispc_fclk_src = OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC,) to get a higher pixel clock's on 3.2/3.4 to easier support displays that needed an exact pixel clock. However since we didn't push that mainline and no other board actually used that in mainline, it was wiped on a cleanup (2). ;) 1: https://github.com/RobertCNelson/stable-kernel/blob/v3.5.x/patches/beagle/0001-beagleboard-reinstate-usage-of-hi-speed-PLL-divider.patch 2: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=b6e695abe710ee1ae248463d325169efac487e17 Regards, -- Robert Nelson http://www.rcn-ee.com/ -- 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_v2] watchdog: Convert twl4030_wdt to watchdog core
Hi, On 09/11/2012 09:01 AM, Jarkko Nikula wrote: Convert the twl4030_wdt watchdog driver to watchdog core. While at there use devm_kzalloc and set the default timeout in order to be able test this driver with a simple shell script. Signed-off-by: Jarkko Nikulajarkko.nik...@jollamobile.com Tested-by: Aaro Koskinenaaro.koski...@iki.fi on my todo list. Kind regards, Wim. -- 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/5] drivers: usb: phy: add a new driver for omap usb2 phy
On 9/27/2012 7:24 AM, Rob Herring wrote: On 09/25/2012 05:06 AM, ABRAHAM, KISHON VIJAY wrote: Hi, On Mon, Sep 24, 2012 at 6:45 PM, Rob Herring robherri...@gmail.com wrote: On 09/06/2012 09:57 AM, Kishon Vijay Abraham I wrote: All phy related programming like enabling/disabling the clocks, powering on/off the phy is taken care of by this driver. It is also used for OTG related functionality like srp. This also includes device tree support for usb2 phy driver and the documentation with device tree binding information is updated. Currently writing to control module register is taken care in this driver which will be removed once the control module driver is in place. Cc: Felipe Balbi ba...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- Documentation/devicetree/bindings/usb/usb-phy.txt | 17 ++ drivers/usb/phy/Kconfig |9 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-usb2.c | 271 + include/linux/usb/omap_usb.h | 46 include/linux/usb/phy_companion.h | 34 +++ 6 files changed, 378 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/usb-phy.txt create mode 100644 drivers/usb/phy/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt new file mode 100644 index 000..80d4148 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt This is a very generic name... @@ -0,0 +1,17 @@ +USB PHY + +OMAP USB2 PHY + +Required properties: + - compatible: Should be ti,omap-usb2 ...for a specific phy. However, I do think a generic binding to describe host ctrlr to phy connections is needed. + - reg : Address and length of the register set for the device. Also +add the address of control module dev conf register until a driver for +control module is added The dts should describe the h/w, not what you need for the current driver. The 2nd reg field does not belong here. Indeed. This was discussed and agreed upon as a interim solution till we have a control module driver in place to write to the control module register. Discussed where and agreed by who? I for one do not agree. Yeah, what was tolerated was the addition of that address inside hwmod data, but I do agree that it should not go into DTS. Regards, Benoit -- 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] omap3isp: Replace cpu_is_omap3630() with ISP revision check
* Laurent Pinchart laurent.pinch...@ideasonboard.com [120927 07:38]: Drivers must not rely on cpu_is_omap* macros (they will soon become private). Use the ISP revision instead to identify the hardware. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Great, thanks for fixing this: Acked-by: Tony Lindgren t...@atomide.com -- 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 v2 2/2] omap3isp: Configure CSI-2 phy based on platform data
* Laurent Pinchart laurent.pinch...@ideasonboard.com [120927 02:52]: Hi Tony, On Wednesday 26 September 2012 15:00:19 Tony Lindgren wrote: Moi Sakari * Sakari Ailus sakari.ai...@iki.fi [120926 14:51]: Configure CSI-2 phy based on platform data in the ISP driver. For that, the new V4L2_CID_IMAGE_SOURCE_PIXEL_RATE control is used. Previously the same was configured from the board code. This patch is dependent on omap3: Provide means for changing CSI2 PHY configuration. Can you please do one more patch to get rid of the last remaining cpu_is_omap check in drivers/media/platform/omap3isp/isp.c? I'm working on that, I'll submit a patch. Thanks acked it. Regards, Tony -- 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: Help needed with remaining plat headers
* Shilimkar, Santosh santosh.shilim...@ti.com [120927 13:34]: On Fri, Sep 28, 2012 at 1:56 AM, Tony Lindgren t...@atomide.com wrote: Please see below a status update on the remaining problem plat headers. Note that all patches should be against current linux next in this case. * Tony Lindgren t...@atomide.com [120920 16:30]: $ ls arch/arm/plat-omap/include/plat/ [..] omap-secure.h Will work with Lokesh to get this one sorted out along with dma. It can be made local to mach-omap2. OK thanks. Tony -- 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/omap: Replace board_ref_clock with enum values
Hi, On Wed, Sep 26, 2012 at 10:12 PM, Vikram Narayanan vikram...@gmail.com wrote: Use the enum for board_ref_clock from linux/wl12xx.h Signed-off-by: Vikram Narayanan vikram...@gmail.com Cc: Tony Lindgren t...@atomide.com Cc: linux-omap@vger.kernel.org --- I'm not subscribed to the list. So please keep me in Cc for the replies. arch/arm/mach-omap2/board-omap4panda.c |3 +-- arch/arm/mach-omap2/board-zoom-peripherals.c |3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) Looks good. Reviewed-by: Pankaj Jangrajangra.pank...@gmail.com -- Pankaj Jangra -- 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] mtd: omap2-nand: avoid unaligned DMA accesses, fall back on prefetch method
On Thu, 2012-09-20 at 17:44 +0200, Arnout Vandecappelle (Essensium/Mind) wrote: It's difficult to reproduce the error, because the buffers are aligned most of the time. Can you just take one of the mtd tests (e.g., mtd_speedtest), amend it a little and make sure it uses unaligned buffers? Perhaps a better method is to fetch the first few unaligned bytes with the prefetch method, and then continue with DMA. However, since it's hard to force an unaligned buffer, it's also hard to test that this method works. Yes, this would be a lot cleaner. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
RE: Help needed with remaining plat headers
Hi Tony, On Fri, Sep 28, 2012 at 01:56:16, Tony Lindgren wrote: Please see below a status update on the remaining problem plat headers. gpmc.h Afzal, can you do a patch for gpmc.h? Yes, I will do it. Regards Afzal
RE: [PATCH v7 08/11] ARM: OMAP2+: gpmc: generic timing calculation
Hi Jon, On Thu, Sep 27, 2012 at 20:46:12, Hunter, Jon wrote: On 09/27/2012 05:07 AM, Mohammed, Afzal wrote: Or maybe should the timings be grouped as ... General Read Async Read Async Address/Data Multiplexed Read Sync Read Sync Address/Data Multiplexed Write Async Write Async Address/Data Multiplexed Write Sync Write Sync Address/Data Multiplexed There may be some duplication but it will be clear where things like ADV timing applies. I would prefer to keep it concise, but no strong opinion on it, if you prefer as above, I will change it. I think that if these represent the main use-case configurations this could add some value. Ok + gpmc_convert_ps_to_ns(gpmc_t); I am wondering if we could avoid this above function and then ... This will be removed once it is confirmed that all the peripherals using custom runtime calculation can work with this generic routine. Then all calculation would be purely in ps. Ok, great. May be add a TODO here to make this clear that this is temporary. Sure Regards Afzal
