date:20130204


On 02/02/2013 12:11 PM, Tony Lindgren wrote:
 * Jon Hunter jon-hun...@ti.com [130201 17:25]:

 On 02/01/2013 03:51 PM, Tony Lindgren wrote:

 How about let's fix this properly to start with so we don't add
 more blockers moving this code to drivers/bus?

 Looks like gpmc_mem_init() gets called from gpmc_probe() so
 we can pass that information in pdev.

 I wondered if you would suggest that ;-)
 
 :)
  
 I definitely can and it is probably best. Things like this become
 painful when we move to device-tree. We really need a generic way for
 passing stuff like this to drivers for omap. Our options are auxdata or
 bus notifiers. I am wondering whether we can plug pdata in the
 omap_device bus notifier for device-tree. Let me know if you have any
 thoughts.
 
 Hmm but in this case can't you just do it based on the compatible
 flag? For legacy systems we also need to pass it in pdata.

This is a boot-time configuration. So really you need to read the
control status register at boot and then determine the mapping. We could
store the address of the control status read in the pdata, but I think
that is a bit of a hack.

 Regarding omap_device, we should find a way to keep the dependencies
 between drivers and the bus code down to minimum. So ideally things
 like this would be only done using just the compatible flag. But the
 pdata we cannot remove quite yet.

Agree. However, there are several drivers today (gpio, dmtimer, mmc,
serial, dss, etc), that make use of a function pointer to
omap_pm_get_dev_context_loss_count() to determine when the peripheral's
state has been lost. When booting with DT this function pointer is not
populated and so with DT we currently have no way to determine this. I
see this as a blocker to migrating completely to DT. Ideally we would
find a way for RPM to handle this and remove the function pointer.
However, right now we still need a generic way to pass this type of
platform data to drivers.

Cheers
Jon
--
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: MAINTAINERS: update

2013-02-04 Thread Balaji T K


On Thursday 31 January 2013 02:52 PM, Venkatraman S wrote:

On Thu, Jan 31, 2013 at 2:22 PM, Balaji T K balaj...@ti.com wrote:

Update Maintainer email for omap_hsmmc,
as Venkatraman will no longer be able to maintain omap_hsmmc driver.

Signed-off-by: Venkatraman S svenk...@gmail.com
Signed-off-by: Balaji T K balaj...@ti.com


Balaji,
   My sign-off is incorrect, as I did not write this patch.

Of course it would great to have a maintainer for this, hence you can add my
Acked-by: Venkatraman S svenk...@gmail.com


Thanks for acking Venkat :-)
yes, you didn't write this patch entirely,
I retained your sign-off because I just modified your
patch[1] to add myself as maintainer :-)

[1]
http://comments.gmane.org/gmane.linux.kernel.mmc/18703

Anyways let me know If you would still like to have your sign-off
dropped from this patch.




---
  MAINTAINERS |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)



--
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 4/5] ARM: OMAP2+: Simplify system timers definitions


On 01/30/2013 11:04 AM, Jon Hunter wrote:
 There is a lot of redundancy in the definitions for the various system
 timers for OMAP2+ devices. For example, the omap3_am33xx_gptimer_timer_init()
 function is the same as the omap3_gp_gptimer_timer_init() function and the
 function omap2_sync32k_timer_init() can be re-used for OMAP4/5 devices.

After further testing, I have found that using the
omap2_sync32k_timer_init() for omap4/5 devices does not work for the
case where we boot with boot parameter clocksource=gp_timer. The
problem is omap4/5 devices, unlike omap2/3 devices, does not have a
clock alias for timer_sys_ck with NULL as the device name. Therefore
we fail to find the parent clock and boot fails.

So I am going to update this patch so that omap4 and omap5 both use
omap4_sync32k_timer_init() and just get rid of the extra function
defined for omap5.

Hope this makes sense.

Cheers
Jon
--
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 01/10] ARM: davinci: move private EDMA API to arm/common

Hi,

On Fri, Feb 01, 2013 at 09:30:03PM +, Russell King - ARM Linux wrote:
I guess to make the MUSB side simpler we would need musb-dma-engine glue
to map dmaengine to the private MUSB API. Then we would have some
starting point to also move inventra (and anybody else) to dmaengine
API.
   
  Why? Inventra is a dedicated device's private DMA controller, why make
   universal DMA driver for it?
  
  because it doesn't make sense to support multiple DMA APIs. We can check
  from MUSB's registers if it was configured with Inventra DMA support and
  based on that we can register MUSB's own DMA Engine to dmaengine API.
 
 Hang on.  This is one of the DMA implementations which is closely
 coupled with the USB and only the USB?  If it is...
 
 I thought this had been discussed _extensively_ before.  I thought the
 resolution on it was:
 1. It would not use the DMA engine API.
 2. It would not live in arch/arm.
 3. It would be placed nearby the USB driver it's associated with.
 
 (1) because we don't use APIs just for the hell of it - think.  Do we
 use the DMA engine API for PCI bus mastering ethernet controllers?  No.
 Do we use it for PCI bus mastering SCSI controllers?  No.  Because the
 DMA is integral to the rest of the device.

that's not really a fair comparison, however. MUSB is used with several
DMA engines.

The only DMA engine which is really coupled with MUSB is the Inventra
DMA engine which comes as an optional feature to the IP. Many users have
opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver.

Granted, CPPI 4.1 makes some assumptions about the fact that it's
handling USB tranfers, but nevertheless, the IP can be, and in fact is,
used with many different DMA engines and driver needs to cope with it.

Current DMA abstraction is quite poor, for example there's no way to
compile support for multiple DMA engines. Code also makes certain, IMO
unnecessary, assumptions about the underlying DMA engine (abstraction is
poor, as said above but it we could follow MUSB's programming guide when
it comes to programming DMA transfers).

Considering all of the above, it's far better to use DMA engine and get
rid of all the mess.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

2013-02-04 Thread Russell King - ARM Linux

On Mon, Feb 04, 2013 at 05:41:53PM +0200, Felipe Balbi wrote:
 Hi,
 
 On Fri, Feb 01, 2013 at 09:30:03PM +, Russell King - ARM Linux wrote:
 I guess to make the MUSB side simpler we would need musb-dma-engine 
 glue
 to map dmaengine to the private MUSB API. Then we would have some
 starting point to also move inventra (and anybody else) to dmaengine
 API.

   Why? Inventra is a dedicated device's private DMA controller, why 
make
universal DMA driver for it?
   
   because it doesn't make sense to support multiple DMA APIs. We can check
   from MUSB's registers if it was configured with Inventra DMA support and
   based on that we can register MUSB's own DMA Engine to dmaengine API.
  
  Hang on.  This is one of the DMA implementations which is closely
  coupled with the USB and only the USB?  If it is...
  
  I thought this had been discussed _extensively_ before.  I thought the
  resolution on it was:
  1. It would not use the DMA engine API.
  2. It would not live in arch/arm.
  3. It would be placed nearby the USB driver it's associated with.
  
  (1) because we don't use APIs just for the hell of it - think.  Do we
  use the DMA engine API for PCI bus mastering ethernet controllers?  No.
  Do we use it for PCI bus mastering SCSI controllers?  No.  Because the
  DMA is integral to the rest of the device.
 
 that's not really a fair comparison, however. MUSB is used with several
 DMA engines.

I only mentioned it because it _was_ brought up as an argument against
using the DMA engine API in the previous discussions.  I'm just reminding
people what was discussed.

 Considering all of the above, it's far better to use DMA engine and get
 rid of all the mess.

Which is what both you and I have been saying for the last 3 or so years
on this subject...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/4] drivers: usb: start using the control module driver

Hi,

On Fri, Feb 01, 2013 at 11:14:24AM -0800, Tony Lindgren wrote:
 * Felipe Balbi ba...@ti.com [130125 02:30]:
  Hi,
  
  On Fri, Jan 25, 2013 at 03:54:00PM +0530, Kishon Vijay Abraham I wrote:
   Start using the control module driver for powering on the PHY and for
   writing to the mailbox instead of writing to the control module
   registers on their own.
   
   Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
   ---
Documentation/devicetree/bindings/usb/omap-usb.txt |4 ++
Documentation/devicetree/bindings/usb/usb-phy.txt  |7 +-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   13 
  
  I'm taking this patch but I'm leaving out the omap_hwmod_44xx_data.c
  change just to kill dependency. Can you send that single change as a
  separate patch which Tony can queue ?
 
 For the USB patches, please also leave out patches touching
 arch/arm/mach-omap2/devices.c. Those are almost guaranteed to
 cause pointless merge conflicts with other branches.
 
 I suggest you set up few immutable branches:
 
 1. Minimal platform_data changes for all your USB changes
 
 This should contain include/linux/platform_data changes and
 changes to arch/arm/*omap* so me and Paul can merge it in too
 to avoid merge conflicts.
 
 2. The rest of the driver/usb changes
 
 This can then be based on #1 branch above.
 
 3. Changes for the .dts files for Benoit
 
 These can be queued separately from #1 and #2 above.

I'm done with all USB stuff for this merge window. The patches which I
didn't take have no dependencies on any drivers/ part. You can easily
queue this through your tree.

cheers

-- 
balbi


signature.asc
Description: Digital signature

[PATCH 00/13] Device tree support for OMAP HS USB Host

Hi,

This patchset adds device tree support for OMAP's High Speed USB Host
subsystem. Board adaptation for Panda and Beagleboard is also provided.

Tested on Beagleboard.

Will only work with Panda if we provide a reference to the PHY clock
generator in the device tree in PATCH 11. I do not know how to do that
as there is no way to provide a phandle to any of the OMAP generated clocks
in the device tree. Suggestions welcome :).

Based on linux-next:next-20130204

Depends on USB: omap-ehci: Move PHY management to PHY driver
g...@github.com:rogerq/linux.git next-usbhost16

The following changes since commit 8c00470e1308d08df1f2b2c7e9a561d868ec0526:

  USB: ehci-omap: Select NOP USB transceiver driver (2013-02-04 16:36:06 +0200)

are available in the git repository at:
  g...@github.com:rogerq/linux.git next-usbhost16-dt

Roger Quadros (13):
  usb: phy: nop: Add device tree support and binding information
  USB: phy: nop: Defer probe if device needs VCC/RESET
  mfd: omap-usb-tll: move configuration code to omap_tll_init()
  mfd: omap-usb-tll: Add device tree support
  USB: ehci-omap: Get platform resources by index rather than by name
  USB: ohci-omap3: Get platform resources by index rather than by name
  USB: ohci-omap3: Add device tree support and binding information
  USB: ehci-omap: Add device tree support and binding information
  mfd: omap-usb-host: Add device tree support and binding information
  ARM: dts: OMAP4: Add HS USB Host IP nodes
  ARM: dts: omap4-panda: Add USB Host support
  ARM: dts: OMAP3: Add HS USB Host IP nodes
  ARM: dts: omap3-beagle: Add USB Host support

 .../devicetree/bindings/mfd/omap-usb-host.txt  |   68 +++
 .../devicetree/bindings/mfd/omap-usb-tll.txt   |   17 ++
 .../devicetree/bindings/usb/omap-ehci.txt  |   34 +++
 .../devicetree/bindings/usb/omap3-ohci.txt |   17 ++
 .../devicetree/bindings/usb/usb-nop-xceiv.txt  |   34 +++
 arch/arm/boot/dts/omap3-beagle.dts |   71 +++
 arch/arm/boot/dts/omap3.dtsi   |   31 +++
 arch/arm/boot/dts/omap4-panda.dts  |   55 +
 arch/arm/boot/dts/omap4.dtsi   |   30 +++
 drivers/mfd/omap-usb-host.c|   90 -
 drivers/mfd/omap-usb-tll.c |  213 ++--
 drivers/mfd/omap-usb.h |5 +-
 drivers/usb/host/ehci-omap.c   |   41 -
 drivers/usb/host/ohci-omap3.c  |   24 ++-
 drivers/usb/otg/nop-usb-xceiv.c|   39 
 include/linux/usb/nop-usb-xceiv.h  |4 +
 16 files changed, 651 insertions(+), 122 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-host.txt
 create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
 create mode 100644 Documentation/devicetree/bindings/usb/omap-ehci.txt
 create mode 100644 Documentation/devicetree/bindings/usb/omap3-ohci.txt
 create mode 100644 Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt

-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 01/13] usb: phy: nop: Add device tree support and binding information

The PHY clock, clock rate, VCC regulator and RESET regulator
can now be provided via device tree.

Signed-off-by: Roger Quadros rog...@ti.com
---
 .../devicetree/bindings/usb/usb-nop-xceiv.txt  |   34 
 drivers/usb/otg/nop-usb-xceiv.c|   31 ++
 2 files changed, 65 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt

diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt 
b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
new file mode 100644
index 000..d7e2726
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
@@ -0,0 +1,34 @@
+USB NOP PHY
+
+Required properties:
+- compatible: should be usb-nop-xceiv
+
+Optional properties:
+- clocks: phandle to the PHY clock. Use as per Documentation/devicetree
+  /bindings/clock/clock-bindings.txt
+  This property is required if clock-frequency is specified.
+
+- clock-names: Should be main_clk
+
+- clock-frequency: the clock frequency (in Hz) that the PHY clock must
+  be configured to.
+
+- vcc-supply: phandle to the regulator that provides RESET to the PHY.
+
+- reset-supply: phandle to the regulator that provides power to the PHY.
+
+Example:
+
+   hsusb1_phy {
+   compatible = usb-nop-xceiv;
+   clock-frequency = 1920;
+   clocks = osc 0;
+   clock-names = main_clk;
+   vcc-supply = hsusb1_vcc_regulator;
+   reset-supply = hsusb1_reset_regulator;
+   };
+
+hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator
+and expects that clock to be configured to 19.2MHz by the NOP PHY driver.
+hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset_regulator
+controls RESET.
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index ac027a1..adbb7ab 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -34,6 +34,7 @@
 #include linux/slab.h
 #include linux/clk.h
 #include linux/regulator/consumer.h
+#include linux/of.h
 
 struct nop_usb_xceiv {
struct usb_phy  phy;
@@ -138,8 +139,19 @@ static int nop_set_host(struct usb_otg *otg, struct 
usb_bus *host)
return 0;
 }
 
+static void nop_xeiv_get_dt_pdata(struct device *dev,
+   struct nop_usb_xceiv_platform_data *pdata)
+{
+   struct device_node *node = dev-of_node;
+   u32 clk_rate;
+
+   if (!of_property_read_u32(node, clock-frequency, clk_rate))
+   pdata-clk_rate = clk_rate;
+}
+
 static int nop_usb_xceiv_probe(struct platform_device *pdev)
 {
+   struct device *dev = pdev-dev;
struct nop_usb_xceiv_platform_data *pdata = pdev-dev.platform_data;
struct nop_usb_xceiv*nop;
enum usb_phy_type   type = USB_PHY_TYPE_USB2;
@@ -153,6 +165,17 @@ static int nop_usb_xceiv_probe(struct platform_device 
*pdev)
if (!nop-phy.otg)
return -ENOMEM;
 
+   if (dev-of_node) {
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   dev_err(dev, Memory allocation failure\n);
+   return -ENOMEM;
+   }
+   nop_xeiv_get_dt_pdata(dev, pdata);
+   } else {
+   pdata = dev-platform_data;
+   }
+
if (pdata)
type = pdata-type;
 
@@ -236,12 +259,20 @@ static int nop_usb_xceiv_remove(struct platform_device 
*pdev)
return 0;
 }
 
+static const struct of_device_id nop_xceiv_dt_ids[] = {
+   { .compatible = usb-nop-xceiv },
+   { }
+};
+
+MODULE_DEVICE_TABLE(of, nop_xceiv_dt_ids);
+
 static struct platform_driver nop_usb_xceiv_driver = {
.probe  = nop_usb_xceiv_probe,
.remove = nop_usb_xceiv_remove,
.driver = {
.name   = nop_usb_xceiv,
.owner  = THIS_MODULE,
+   .of_match_table = of_match_ptr(nop_xceiv_dt_ids),
},
 };
 
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 02/13] USB: phy: nop: Defer probe if device needs VCC/RESET

Add 2 flags, needs_vcc and needs_reset to platform data.
If the flag is set and the regulator couldn't be found
then we bail out with -EPROBE_DEFER.

For device tree boot we depend on presensce of vcc-supply/
reset-supply properties to decide if we should bail out
with -EPROBE_DEFER or just continue in case the regulator
can't be found.

This is required for proper functionality in cases where the
regulator is needed but is probed later than the PHY device.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/usb/otg/nop-usb-xceiv.c   |8 
 include/linux/usb/nop-usb-xceiv.h |4 
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index adbb7ab..7860e7569 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -147,6 +147,10 @@ static void nop_xeiv_get_dt_pdata(struct device *dev,
 
if (!of_property_read_u32(node, clock-frequency, clk_rate))
pdata-clk_rate = clk_rate;
+   if (of_property_read_bool(node, vcc-supply))
+   pdata-needs_vcc = true;
+   if (of_property_read_bool(node, reset-supply))
+   pdata-needs_reset = true;
 }
 
 static int nop_usb_xceiv_probe(struct platform_device *pdev)
@@ -205,12 +209,16 @@ static int nop_usb_xceiv_probe(struct platform_device 
*pdev)
if (IS_ERR(nop-vcc)) {
dev_dbg(pdev-dev, Error getting vcc regulator: %ld\n,
PTR_ERR(nop-vcc));
+   if (pdata-needs_vcc)
+   return -EPROBE_DEFER;
}
 
nop-reset = devm_regulator_get(pdev-dev, reset);
if (IS_ERR(nop-reset)) {
dev_dbg(pdev-dev, Error getting reset regulator: %ld\n,
PTR_ERR(nop-reset));
+   if (pdata-needs_reset)
+   return -EPROBE_DEFER;
}
 
nop-dev= pdev-dev;
diff --git a/include/linux/usb/nop-usb-xceiv.h 
b/include/linux/usb/nop-usb-xceiv.h
index 3265b61..148d351 100644
--- a/include/linux/usb/nop-usb-xceiv.h
+++ b/include/linux/usb/nop-usb-xceiv.h
@@ -6,6 +6,10 @@
 struct nop_usb_xceiv_platform_data {
enum usb_phy_type type;
unsigned long clk_rate;
+
+   /* if set fails with -EPROBE_DEFER if can't get regulator */
+   unsigned int needs_vcc:1;
+   unsigned int needs_reset:1;
 };
 
 #if defined(CONFIG_NOP_USB_XCEIV) || (defined(CONFIG_NOP_USB_XCEIV_MODULE)  
defined(MODULE))
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 04/13] mfd: omap-usb-tll: Add device tree support

Enable this driver to probe in device tree boot.

CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
 .../devicetree/bindings/mfd/omap-usb-tll.txt   |   17 +
 drivers/mfd/omap-usb-tll.c |9 +
 2 files changed, 26 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-tll.txt

diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt 
b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
new file mode 100644
index 000..835cf4f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
@@ -0,0 +1,17 @@
+OMAP HS USB Host TLL (Transceiver-Less Interface)
+
+Required properties:
+
+- compatible : should be ti,usbhs-tll
+- reg : should contain one register range i.e. start and length
+- interrupts : should contain the TLL module's interrupt
+- ti,hwmod : must contain usb_tll_hs
+
+Example:
+
+   usbhstll: usbhstll@0x4a062000 {
+   compatible = ti,usbhs-tll;
+   reg = 0x4a062000 0x1000;
+   interrupts = 78;
+   ti,hwmods = usb_tll_hs;
+ };
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index f7d2568..f7afb22 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -28,6 +28,7 @@
 #include linux/err.h
 #include linux/pm_runtime.h
 #include linux/platform_data/usb-omap.h
+#include linux/of.h
 
 #define USBTLL_DRIVER_NAME usbhs_tll
 
@@ -311,10 +312,18 @@ static int usbtll_omap_remove(struct platform_device 
*pdev)
return 0;
 }
 
+static const struct of_device_id usbtll_omap_dt_ids[] = {
+   { .compatible = ti,usbhs-tll },
+   { }
+};
+
+MODULE_DEVICE_TABLE(of, usbtll_omap_dt_ids);
+
 static struct platform_driver usbtll_omap_driver = {
.driver = {
.name   = (char *)usbtll_driver_name,
.owner  = THIS_MODULE,
+   .of_match_table = of_match_ptr(usbtll_omap_dt_ids),
},
.probe  = usbtll_omap_probe,
.remove = usbtll_omap_remove,
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 05/13] USB: ehci-omap: Get platform resources by index rather than by name

Since there is only one resource per type we don't really need
to use resource name to obtain it. This also also makes it easier
for device tree adaptation.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/usb/host/ehci-omap.c |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 60c4a2d..5a831aef 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -148,14 +148,13 @@ static int ehci_hcd_omap_probe(struct platform_device 
*pdev)
return -ENODEV;
}
 
-   irq = platform_get_irq_byname(pdev, ehci-irq);
+   irq = platform_get_irq(pdev, 0);
if (irq  0) {
dev_err(dev, EHCI irq failed\n);
return -ENODEV;
}
 
-   res =  platform_get_resource_byname(pdev,
-   IORESOURCE_MEM, ehci);
+   res =  platform_get_resource(pdev, IORESOURCE_MEM, 0);
regs = devm_ioremap_resource(dev, res);
if (IS_ERR(regs)) {
dev_err(dev, Resource request/ioremap failed\n);
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 03/13] mfd: omap-usb-tll: move configuration code to omap_tll_init()

This is because we want to get rid of platform_data usage from probe().
The only information we need is PORT_MODE, and this can be supplied
to us by the user (i.e. omap-usb-host.c).

We also move channel clock management from runtime PM handlers into
omap_tll_enable/disable().

CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/mfd/omap-usb-host.c |7 +-
 drivers/mfd/omap-usb-tll.c  |  204 +--
 drivers/mfd/omap-usb.h  |5 +-
 3 files changed, 107 insertions(+), 109 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 502a779..f8ed08e 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -278,7 +278,7 @@ static int usbhs_runtime_resume(struct device *dev)
 
dev_dbg(dev, usbhs_runtime_resume\n);
 
-   omap_tll_enable();
+   omap_tll_enable(pdata);
 
if (!IS_ERR(omap-ehci_logic_fck))
clk_enable(omap-ehci_logic_fck);
@@ -353,7 +353,7 @@ static int usbhs_runtime_suspend(struct device *dev)
if (!IS_ERR(omap-ehci_logic_fck))
clk_disable(omap-ehci_logic_fck);
 
-   omap_tll_disable();
+   omap_tll_disable(pdata);
 
return 0;
 }
@@ -499,6 +499,9 @@ static int usbhs_omap_probe(struct platform_device *pdev)
 
omap-pdata = pdata;
 
+   /* Initialize the TLL subsystem */
+   omap_tll_init(pdata);
+
pm_runtime_enable(dev);
 
platform_set_drvdata(pdev, omap);
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 0aef1a7..f7d2568 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -1,8 +1,9 @@
 /**
  * omap-usb-tll.c - The USB TLL driver for OMAP EHCI  OHCI
  *
- * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2012-2013 Texas Instruments Incorporated - http://www.ti.com
  * Author: Keshava Munegowda keshava_mgo...@ti.com
+ * Author: Roger Quadros rog...@ti.com
  *
  * This program is free software: you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2  of
@@ -105,8 +106,8 @@
 
 struct usbtll_omap {
int nch;/* num. of channels */
-   struct usbhs_omap_platform_data *pdata;
struct clk  **ch_clk;
+   void __iomem*base;
 };
 
 /*-*/
@@ -210,14 +211,10 @@ static unsigned ohci_omap3_fslsmode(enum 
usbhs_omap_port_mode mode)
 static int usbtll_omap_probe(struct platform_device *pdev)
 {
struct device   *dev =  pdev-dev;
-   struct usbhs_omap_platform_data *pdata = dev-platform_data;
-   void __iomem*base;
struct resource *res;
struct usbtll_omap  *tll;
-   unsignedreg;
int ret = 0;
int i, ver;
-   bool needs_tll;
 
dev_dbg(dev, starting TI HSUSB TLL Controller\n);
 
@@ -227,16 +224,9 @@ static int usbtll_omap_probe(struct platform_device *pdev)
return -ENOMEM;
}
 
-   if (!pdata) {
-   dev_err(dev, Platform data missing\n);
-   return -ENODEV;
-   }
-
-   tll-pdata = pdata;
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   base = devm_request_and_ioremap(dev, res);
-   if (!base) {
+   tll-base = devm_request_and_ioremap(dev, res);
+   if (!tll-base) {
ret = -EADDRNOTAVAIL;
dev_err(dev, Resource request/ioremap failed:%d\n, ret);
return ret;
@@ -246,7 +236,7 @@ static int usbtll_omap_probe(struct platform_device *pdev)
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
 
-   ver =  usbtll_read(base, OMAP_USBTLL_REVISION);
+   ver =  usbtll_read(tll-base, OMAP_USBTLL_REVISION);
switch (ver) {
case OMAP_USBTLL_REV1:
case OMAP_USBTLL_REV4:
@@ -283,11 +273,77 @@ static int usbtll_omap_probe(struct platform_device *pdev)
dev_dbg(dev, can't get clock : %s\n, clkname);
}
 
+   pm_runtime_put_sync(dev);
+   /* only after this can omap_tll_enable/disable work */
+   spin_lock(tll_lock);
+   tll_dev = dev;
+   spin_unlock(tll_lock);
+
+   return 0;
+
+err_clk_alloc:
+   pm_runtime_put_sync(dev);
+   pm_runtime_disable(dev);
+
+   return ret;
+}
+
+/**
+ * usbtll_omap_remove - shutdown processing for UHH  TLL HCDs
+ * @pdev: USB Host Controller being removed
+ *
+ * Reverses the effect of usbtll_omap_probe().
+ */
+static int usbtll_omap_remove(struct platform_device *pdev)
+{
+   struct usbtll_omap *tll =

[PATCH 06/13] USB: ohci-omap3: Get platform resources by index rather than by name

Since there is only one resource per type we don't really need
to use resource name to obtain it. This also also makes it easier
for device tree adaptation.

Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/usb/host/ohci-omap3.c |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/ohci-omap3.c b/drivers/usb/host/ohci-omap3.c
index eb35d96..5ed28c5 100644
--- a/drivers/usb/host/ohci-omap3.c
+++ b/drivers/usb/host/ohci-omap3.c
@@ -141,14 +141,13 @@ static int ohci_hcd_omap3_probe(struct platform_device 
*pdev)
return -ENODEV;
}
 
-   irq = platform_get_irq_byname(pdev, ohci-irq);
+   irq = platform_get_irq(pdev, 0);
if (irq  0) {
dev_err(dev, OHCI irq failed\n);
return -ENODEV;
}
 
-   res = platform_get_resource_byname(pdev,
-   IORESOURCE_MEM, ohci);
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(dev, UHH OHCI get resource failed\n);
return -ENOMEM;
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/13] USB: ohci-omap3: Add device tree support and binding information

Allows the OHCI controller found in OMAP3 and later chips to
be specified via device tree.

Signed-off-by: Roger Quadros rog...@ti.com
---
 .../devicetree/bindings/usb/omap3-ohci.txt |   17 +
 drivers/usb/host/ohci-omap3.c  |   19 +++
 2 files changed, 36 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/omap3-ohci.txt

diff --git a/Documentation/devicetree/bindings/usb/omap3-ohci.txt 
b/Documentation/devicetree/bindings/usb/omap3-ohci.txt
new file mode 100644
index 000..aabbfdc
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap3-ohci.txt
@@ -0,0 +1,17 @@
+OMAP HS USB OHCI controller (OMAP3 and later)
+
+Required properties:
+
+- compatible: should be ti,omap3-ohci
+- reg: should contain one register range i.e. start and length
+- interrupt-parent: phandle to the interrupt controller
+- interrupts: description of the interrupt line
+
+Example for OMAP4:
+
+usbhsohci: ohci@0x4a064800 {
+   compatible = ti,omap3-ohci, usb-ohci;
+   reg = 0x4a064800 0x400;
+   interrupt-parent = gic;
+   interrupts = 0 76 0x4;
+};
diff --git a/drivers/usb/host/ohci-omap3.c b/drivers/usb/host/ohci-omap3.c
index 5ed28c5..b0bfab1 100644
--- a/drivers/usb/host/ohci-omap3.c
+++ b/drivers/usb/host/ohci-omap3.c
@@ -31,6 +31,8 @@
 
 #include linux/platform_device.h
 #include linux/pm_runtime.h
+#include linux/of.h
+#include linux/dma-mapping.h
 
 /*-*/
 
@@ -112,6 +114,8 @@ static const struct hc_driver ohci_omap3_hc_driver = {
 
 /*-*/
 
+static u64 omap_ohci_dma_mask = DMA_BIT_MASK(32);
+
 /*
  * configure so an HC device and id are always provided
  * always called with process context; sleeping is OK
@@ -159,6 +163,13 @@ static int ohci_hcd_omap3_probe(struct platform_device 
*pdev)
return -ENOMEM;
}
 
+   /*
+* Right now device-tree probed devices don't get dma_mask set.
+* Since shared usb code relies on it, set it here for now.
+* Once we have dma capability bindings this can go away.
+*/
+   if (!pdev-dev.dma_mask)
+   pdev-dev.dma_mask = omap_ohci_dma_mask;
 
hcd = usb_create_hcd(ohci_omap3_hc_driver, dev,
dev_name(dev));
@@ -228,12 +239,20 @@ static void ohci_hcd_omap3_shutdown(struct 
platform_device *pdev)
hcd-driver-shutdown(hcd);
 }
 
+static const struct of_device_id omap_ohci_dt_ids[] = {
+   { .compatible = ti,omap3-ohci },
+   { }
+};
+
+MODULE_DEVICE_TABLE(of, omap_ohci_dt_ids);
+
 static struct platform_driver ohci_hcd_omap3_driver = {
.probe  = ohci_hcd_omap3_probe,
.remove = ohci_hcd_omap3_remove,
.shutdown   = ohci_hcd_omap3_shutdown,
.driver = {
.name   = ohci-omap3,
+   .of_match_table = of_match_ptr(omap_ohci_dt_ids),
},
 };
 
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 09/13] mfd: omap-usb-host: Add device tree support and binding information

Allows the OMAP HS USB host controller to be specified
via device tree.

CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
 .../devicetree/bindings/mfd/omap-usb-host.txt  |   68 
 drivers/mfd/omap-usb-host.c|   83 ++--
 2 files changed, 145 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-host.txt

diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt 
b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
new file mode 100644
index 000..2196893
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
@@ -0,0 +1,68 @@
+OMAP HS USB Host
+
+Required properties:
+
+- compatible: should be ti,usbhs-host
+- reg: should contain one register range i.e. start and length
+- ti,hwmods: must contain usb_host_hs
+
+Optional properties:
+
+- nports: number of USB ports. Usually this is automatically detected
+  from the IP's revision register but can be overridden by specifying
+  this property.
+
+- portN_mode: Integer specifying the port mode for port N, where N can be
+  from 1 to nports. The port mode must be as per enum usbhs_omap_port_mode
+  in include/linux/platform_data/usb-omap.h
+  If the port mode is not specified, that port is treated as unused.
+
+- single_ulpi_bypass: Must be present if the controller contains a single
+  ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1
+
+Required properties if child node exists:
+
+- #address-cells: Must be 1
+- #size-cells: Must be 1
+- ranges: must be present
+
+Properties for children:
+
+The OMAP HS USB Host subsystem contains EHCI and OHCI controllers.
+See Documentation/devicetree/bindings/usb/omap-ehci.txt and
+omap3-ohci.txt
+
+Example for OMAP4:
+
+usbhshost: usbhshost@0x4a064000 {
+   compatible = ti,usbhs-host;
+   reg = 0x4a064000 0x800;
+   ti,hwmods = usb_host_hs;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+
+   usbhsohci: ohci@0x4a064800 {
+   compatible = ti,omap3-ohci, usb-ohci;
+   reg = 0x4a064800 0x400;
+   interrupt-parent = gic;
+   interrupts = 0 76 0x4;
+   };
+
+   usbhsehci: ehci@0x4a064c00 {
+   compatible = ti,omap-ehci, usb-ehci;
+   reg = 0x4a064c00 0x400;
+   interrupt-parent = gic;
+   interrupts = 0 77 0x4;
+   };
+};
+
+usbhshost {
+   port1_mode = 1; /* OMAP_EHCI_PORT_MODE_PHY */
+   port2_mode = 2; /* OMAP_EHCI_PORT_MODE_TLL */
+   port3_mode = 1; /* OMAP_EHCI_PORT_MODE_PHY */
+};
+
+usbhsehci {
+   phy = hsusb1_phy 0 hsusb3_phy;
+};
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index f8ed08e..0f67856 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -1,8 +1,9 @@
 /**
  * omap-usb-host.c - The USBHS core driver for OMAP EHCI  OHCI
  *
- * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2011-2013 Texas Instruments Incorporated - http://www.ti.com
  * Author: Keshava Munegowda keshava_mgo...@ti.com
+ * Author: Roger Quadros rog...@ti.com
  *
  * This program is free software: you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2  of
@@ -27,6 +28,8 @@
 #include linux/platform_device.h
 #include linux/platform_data/usb-omap.h
 #include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_platform.h
 
 #include omap-usb.h
 
@@ -464,6 +467,37 @@ static void omap_usbhs_init(struct device *dev)
pm_runtime_put_sync(dev);
 }
 
+static int usbhs_omap_get_dt_pdata(struct device_node *node,
+   struct usbhs_omap_platform_data *pdata)
+{
+   int ret, i;
+
+   ret = of_property_read_u32(node, nports, pdata-nports);
+   if (ret)
+   pdata-nports = 0;
+
+   /* get port modes */
+   for (i = 0; i  OMAP3_HS_USB_PORTS; i++) {
+   char prop[11];
+
+   snprintf(prop, sizeof(prop), port%d_mode, i + 1);
+   ret = of_property_read_u32(node, prop, pdata-port_mode[i]);
+   if (ret)
+   pdata-port_mode[i] = OMAP_USBHS_PORT_MODE_UNUSED;
+   }
+
+   /* get flags */
+   pdata-single_ulpi_bypass = of_property_read_bool(node,
+   single_ulpi_bypass);
+   return 0;
+}
+
+static struct of_device_id usbhs_child_match_table[] __initdata = {
+   { .compatible = ti,omap-ehci, },
+   { .compatible = ti,omap-ohci, },
+   { }
+};
+
 /**
  * usbhs_omap_probe - initialize TI-based HCDs
  *
@@ -479,6 +513,21 @@ static int usbhs_omap_probe(struct platform_device *pdev)
int i;
boolneed_logic_fck;
 
+   if (dev-of_node) {
+   /* For DT boot we populate platform data from OF node */
+

[PATCH 10/13] ARM: dts: OMAP4: Add HS USB Host IP nodes

Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.

Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/boot/dts/omap4.dtsi |   30 ++
 1 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..3429280 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -529,5 +529,35 @@
ti,hwmods = timer11;
ti,timer-pwm;
};
+
+   usbhstll: usbhstll@0x4a062000 {
+   compatible = ti,usbhs-tll;
+   reg = 0x4a062000 0x1000;
+   interrupts = 0 78 0x4;
+   ti,hwmods = usb_tll_hs;
+   };
+
+   usbhshost: usbhshost@0x4a064000 {
+   compatible = ti,usbhs-host;
+   reg = 0x4a064000 0x800;
+   ti,hwmods = usb_host_hs;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+
+   usbhsohci: ohci@0x4a064800 {
+   compatible = ti,omap3-ohci, usb-ohci;
+   reg = 0x4a064800 0x400;
+   interrupt-parent = gic;
+   interrupts = 0 76 0x4;
+   };
+
+   usbhsehci: ehci@0x4a064c00 {
+   compatible = ti,omap-ehci, usb-ehci;
+   reg = 0x4a064c00 0x400;
+   interrupt-parent = gic;
+   interrupts = 0 77 0x4;
+   };
+   };
};
 };
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 08/13] USB: ehci-omap: Add device tree support and binding information

Allows the OMAP EHCI controller to be specified via device tree.

Signed-off-by: Roger Quadros rog...@ti.com
---
 .../devicetree/bindings/usb/omap-ehci.txt  |   34 ++
 drivers/usb/host/ehci-omap.c   |   36 +++-
 2 files changed, 69 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/omap-ehci.txt

diff --git a/Documentation/devicetree/bindings/usb/omap-ehci.txt 
b/Documentation/devicetree/bindings/usb/omap-ehci.txt
new file mode 100644
index 000..90e6e3a
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-ehci.txt
@@ -0,0 +1,34 @@
+OMAP HS USB EHCI controller
+
+This device is usually the child of the omap-usb-host
+Documentation/devicetree/bindings/mfd/omap-usb-host.txt
+
+Required properties:
+
+- compatible: should be ti,omap-ehci
+- reg: should contain one register range i.e. start and length
+- interrupt-parent: phandle to the interrupt controller
+- interrupts: description of the interrupt line
+
+Optional properties:
+
+- phy: list of phandles to PHY nodes.
+  This property is required if at least one of the ports are in
+  PHY mode i.e. OMAP_EHCI_PORT_MODE_PHY
+
+To specify the port mode, see
+Documentation/devicetree/bindings/mfd/omap-usb-host.txt
+
+Example for OMAP4:
+
+usbhsehci: ehci@0x4a064c00 {
+   compatible = ti,omap-ehci, usb-ehci;
+   reg = 0x4a064c00 0x400;
+   interrupt-parent = gic;
+   interrupts = 0 77 0x4;
+};
+
+usbhsehci {
+   phy = hsusb1_phy 0 hsusb3_phy;
+};
+
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 5a831aef..15cc419 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -48,6 +48,8 @@
 #include linux/clk.h
 #include linux/usb.h
 #include linux/usb/hcd.h
+#include linux/of.h
+#include linux/dma-mapping.h
 
 #include ehci.h
 
@@ -121,6 +123,8 @@ static const struct ehci_driver_overrides 
ehci_omap_overrides __initdata = {
.extra_priv_size = sizeof(struct omap_hcd),
 };
 
+static u64 omap_ehci_dma_mask = DMA_BIT_MASK(32);
+
 /**
  * ehci_hcd_omap_probe - initialize TI-based HCDs
  *
@@ -148,6 +152,17 @@ static int ehci_hcd_omap_probe(struct platform_device 
*pdev)
return -ENODEV;
}
 
+   /* For DT boot, get platform data from parent. i.e. usbhshost */
+   if (dev-of_node) {
+   pdata = dev-parent-platform_data;
+   dev-platform_data = pdata;
+   }
+
+   if (!pdata) {
+   dev_err(dev, Missing platform data\n);
+   return -ENODEV;
+   }
+
irq = platform_get_irq(pdev, 0);
if (irq  0) {
dev_err(dev, EHCI irq failed\n);
@@ -161,6 +176,14 @@ static int ehci_hcd_omap_probe(struct platform_device 
*pdev)
return PTR_ERR(regs);
}
 
+   /*
+* Right now device-tree probed devices don't get dma_mask set.
+* Since shared usb code relies on it, set it here for now.
+* Once we have dma capability bindings this can go away.
+*/
+   if (!pdev-dev.dma_mask)
+   pdev-dev.dma_mask = omap_ehci_dma_mask;
+
hcd = usb_create_hcd(ehci_omap_hc_driver, dev,
dev_name(dev));
if (!hcd) {
@@ -185,7 +208,10 @@ static int ehci_hcd_omap_probe(struct platform_device 
*pdev)
continue;
 
/* get the PHY device */
-   phy = devm_usb_get_phy_dev(dev, i);
+   if (dev-of_node)
+   phy = devm_usb_get_phy_by_phandle(dev, phy, i);
+   else
+   phy = devm_usb_get_phy_dev(dev, i);
if (IS_ERR(phy) || !phy) {
ret = IS_ERR(phy) ? PTR_ERR(phy) : -ENODEV;
dev_err(dev, Can't get PHY device for port %d: %d\n,
@@ -275,6 +301,13 @@ static void ehci_hcd_omap_shutdown(struct platform_device 
*pdev)
hcd-driver-shutdown(hcd);
 }
 
+static const struct of_device_id omap_ehci_dt_ids[] = {
+   { .compatible = ti,omap-ehci },
+   { }
+};
+
+MODULE_DEVICE_TABLE(of, omap_ehci_dt_ids);
+
 static struct platform_driver ehci_hcd_omap_driver = {
.probe  = ehci_hcd_omap_probe,
.remove = ehci_hcd_omap_remove,
@@ -283,6 +316,7 @@ static struct platform_driver ehci_hcd_omap_driver = {
/*.resume   = ehci_hcd_omap_resume, */
.driver = {
.name   = hcd_name,
+   .of_match_table = of_match_ptr(omap_ehci_dt_ids),
}
 };
 
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 12/13] ARM: dts: OMAP3: Add HS USB Host IP nodes

Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.

Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/boot/dts/omap3.dtsi |   31 +++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..39442b4 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,36 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+   usbhstll: usbhstll@0x48062000 {
+   compatible = ti,usbhs-tll;
+   reg = 0x48062000 0x1000;
+   interrupts = 78;
+   ti,hwmods = usb_tll_hs;
+   };
+
+   usbhshost: usbhshost@0x48064000 {
+   compatible = ti,usbhs-host;
+   reg = 0x48064000 0x400;
+   ti,hwmods = usb_host_hs;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+
+   usbhsohci: ohci@0x48064400 {
+   compatible = ti,omap3-ohci, usb-ohci;
+   reg = 0x48064400 0x400;
+   interrupt-parent = intc;
+   interrupts = 76;
+   };
+
+   usbhsehci: ehci@0x48064800 {
+   compatible = ti,omap-ehci, usb-ehci;
+   reg = 0x48064800 0x400;
+   interrupt-parent = intc;
+   interrupts = 77;
+   };
+   };
+
};
 };
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 13/13] ARM: dts: omap3-beagle: Add USB Host support

Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.

Also provide pin multiplexer information for USB host
pins.

Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/boot/dts/omap3-beagle.dts |   71 
 1 files changed, 71 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index f624dc8..2c4a6d6 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -38,6 +38,57 @@
};
};
 
+   /* HS USB Port 2 RESET */
+   hsusb2_reset: hsusb2_reset_reg {
+   compatible = regulator-fixed;
+   regulator-name = hsusb2_reset;
+   regulator-min-microvolt = 330;
+   regulator-max-microvolt = 330;
+   gpio = gpio5 19 0;   /* gpio_147 */
+   startup-delay-us = 7;
+   enable-active-high;
+   };
+
+   /* HS USB Port 2 Power */
+   hsusb2_power: hsusb2_power_reg {
+   compatible = regulator-fixed;
+   regulator-name = hsusb2_vbus;
+   regulator-min-microvolt = 330;
+   regulator-max-microvolt = 330;
+   gpio = twl_gpio 18 0;/* GPIO LEDA */
+   startup-delay-us = 7;
+   };
+
+   /* HS USB Host PHY on PORT 2 */
+   hsusb2_phy: hsusb2_phy {
+   compatible = usb-nop-xceiv;
+   reset-supply = hsusb2_reset;
+   vcc-supply = hsusb2_power;
+   };
+};
+
+omap3_pmx_core {
+   pinctrl-names = default;
+   pinctrl-0 = 
+   hsusbb2_pins
+   ;
+
+   hsusbb2_pins: pinmux_hsusbb2_pins {
+   pinctrl-single,pins = 
+   0x5c0 0x3  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk OUTPUT */
+   0x5c2 0x3  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
+   0x5c4 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
+   0x5c6 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
+   0x5c8 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
+   0x5cA 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
+   0x1a4 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
+   0x1a6 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
+   0x1a8 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
+   0x1aa 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
+   0x1ac 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
+   0x1ae 0x10b  /* 
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
+   ;
+   };
 };
 
 i2c1 {
@@ -65,3 +116,23 @@
 mmc3 {
status = disabled;
 };
+
+usbhshost {
+   port2_mode = 1; /* OMAP_EHCI_PORT_MODE_PHY */
+};
+
+usbhsehci {
+   phy = 0 hsusb2_phy;
+};
+
+twl_gpio {
+   ti,use-leds;
+   /* pullups: BIT(1) */
+   ti,pullups = 0x02;
+   /*
+* pulldowns:
+* BIT(2), BIT(6), BIT(7), BIT(8), BIT(13)
+* BIT(15), BIT(16), BIT(17)
+*/
+   ti,pulldowns = 0x03a1c4;
+};
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 11/13] ARM: dts: omap4-panda: Add USB Host support

Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.

Also provide pin multiplexer information for the USB host
pins.

Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/boot/dts/omap4-panda.dts |   55 +
 1 files changed, 55 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda.dts 
b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..fe2d3d4 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -57,6 +57,35 @@
AFML, Line In,
AFMR, Line In;
};
+
+   /* HS USB Port 1 RESET */
+   hsusb1_reset: hsusb1_reset_reg {
+   compatible = regulator-fixed;
+   regulator-name = hsusb1_reset;
+   regulator-min-microvolt = 330;
+   regulator-max-microvolt = 330;
+   gpio = gpio2 30 0;   /* gpio_62 */
+   startup-delay-us = 7;
+   enable-active-high;
+   };
+
+   /* HS USB Port 1 Power */
+   hsusb1_power: hsusb1_power_reg {
+   compatible = regulator-fixed;
+   regulator-name = hsusb1_vbus;
+   regulator-min-microvolt = 330;
+   regulator-max-microvolt = 330;
+   gpio = gpio1 1 0;/* gpio_1 */
+   startup-delay-us = 7;
+   enable-active-high;
+   };
+
+   /* HS USB Host PHY on PORT 1 */
+   hsusb1_phy: hsusb1_phy {
+   compatible = usb-nop-xceiv;
+   reset-supply = hsusb1_reset;
+   vcc-supply = hsusb1_power;
+   };
 };
 
 omap4_pmx_core {
@@ -67,6 +96,7 @@
mcbsp1_pins
dss_hdmi_pins
tpd12s015_pins
+   hsusbb1_pins
;
 
twl6040_pins: pinmux_twl6040_pins {
@@ -110,6 +140,23 @@
0x58 0x10b  /* hdmi_hpd.gpio_63 INPUT PULLDOWN | 
MODE3 */
;
};
+
+   hsusbb1_pins: pinmux_hsusbb1_pins {
+   pinctrl-single,pins = 
+   0x82 0x10C  /* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk INPUT | PULLDOWN */
+   0x84 0x4/* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
+   0x86 0x104  /* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
+   0x88 0x104  /* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
+   0x8a 0x104  /* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
+   0x8c 0x104  /* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
+   0x8e 0x104  /* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
+   0x90 0x104  /* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
+   0x92 0x104  /* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
+   0x94 0x104  /* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
+   0x96 0x104  /* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
+   0x98 0x104  /* 
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
+   ;
+   };
 };
 
 i2c1 {
@@ -206,3 +253,11 @@
 twl_usb_comparator {
usb-supply = vusb;
 };
+
+usbhshost {
+   port1_mode = 1; /* OMAP_EHCI_PORT_MODE_PHY */
+};
+
+usbhsehci {
+   phy = hsusb1_phy;
+};
-- 
1.7.4.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

2013-02-04 Thread Sergei Shtylyov

Hello.

On 02/04/2013 06:41 PM, Felipe Balbi wrote:

 I guess to make the MUSB side simpler we would need musb-dma-engine glue
 to map dmaengine to the private MUSB API. Then we would have some
 starting point to also move inventra (and anybody else) to dmaengine
 API.

Why? Inventra is a dedicated device's private DMA controller, why make
 universal DMA driver for it?

 because it doesn't make sense to support multiple DMA APIs. We can check
 from MUSB's registers if it was configured with Inventra DMA support and
 based on that we can register MUSB's own DMA Engine to dmaengine API.

 Hang on.  This is one of the DMA implementations which is closely
 coupled with the USB and only the USB?  If it is...

 I thought this had been discussed _extensively_ before.  I thought the
 resolution on it was:
 1. It would not use the DMA engine API.
 2. It would not live in arch/arm.
 3. It would be placed nearby the USB driver it's associated with.

 (1) because we don't use APIs just for the hell of it - think.  Do we
 use the DMA engine API for PCI bus mastering ethernet controllers?  No.
 Do we use it for PCI bus mastering SCSI controllers?  No.  Because the
 DMA is integral to the rest of the device.

 that's not really a fair comparison, however. MUSB is used with several
 DMA engines.

 The only DMA engine which is really coupled with MUSB is the Inventra
 DMA engine which comes as an optional feature to the IP. Many users have

   That's not quite true. At least CPPI 3.0 is coupled with MUSB as well. The
programming interface is MUSB specific, and differs from that of the EMAC driver
which also uses CPPI 3.0 (however, the DMA descriptor format is the same between
both, IIRC).

 opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
 Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver.

 Granted, CPPI 4.1 makes some assumptions about the fact that it's
 handling USB tranfers,

   What CPPI 4.1 code makes this assumptions? MUSB DMA driver? Then it's just
natural. Generic CPPI 4.1 support code (as was posted for both mach-dacinci/ or
common/ placement) made no such assumptions.

 but nevertheless, the IP can be, and in fact is,
 used with many different DMA engines and driver needs to cope with it.

   What IP, CPPI 4.1 or MUSB?

 Current DMA abstraction is quite poor, for example there's no way to
 compile support for multiple DMA engines. Code also makes certain, IMO
 unnecessary, assumptions about the underlying DMA engine (abstraction is
 poor, as said above but it we could follow MUSB's programming guide when
 it comes to programming DMA transfers).

   Don't know, I was quite content with the abstraction when writing CPPI 4.1
driver for MUSB...

 Considering all of the above, it's far better to use DMA engine and get
 rid of all the mess.

   In my eyes, getting rid of the mess doesn't justify breaking the rules that
Russell formulated above.

WBR, Sergei

--
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 01/10] ARM: davinci: move private EDMA API to arm/common

Hi,

On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
  opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
  Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver.
 
  Granted, CPPI 4.1 makes some assumptions about the fact that it's
  handling USB tranfers,
 
What CPPI 4.1 code makes this assumptions? MUSB DMA driver? Then it's just

HW makes the asumptions

  but nevertheless, the IP can be, and in fact is,
  used with many different DMA engines and driver needs to cope with it.
 
What IP, CPPI 4.1 or MUSB?

MUSB

  Current DMA abstraction is quite poor, for example there's no way to
  compile support for multiple DMA engines. Code also makes certain, IMO
  unnecessary, assumptions about the underlying DMA engine (abstraction is
  poor, as said above but it we could follow MUSB's programming guide when
  it comes to programming DMA transfers).
 
Don't know, I was quite content with the abstraction when writing CPPI 4.1
 driver for MUSB...

look closer. The whole:

if (is_cppi())
foo();
else if (is_inventra())
bar();
else if (is_omap_sdma())
baz();

is bogus.

  Considering all of the above, it's far better to use DMA engine and get
  rid of all the mess.
 
In my eyes, getting rid of the mess doesn't justify breaking the rules that
 Russell formulated above.

MUSB is no PCI, there is no single, standard interface to the DMA
engine (unlike Synopsys' dwc-usb3 and dwc-usb2, where we don't use DMA
engine), every DMA engine comes with its own set of registers, its own
programming model and so forth.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

2013-02-04 Thread Sergei Shtylyov

Hello.

On 02/04/2013 07:47 PM, Felipe Balbi wrote:

 On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
 opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
 Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver.

 Granted, CPPI 4.1 makes some assumptions about the fact that it's
 handling USB tranfers,

What CPPI 4.1 code makes this assumptions? MUSB DMA driver? Then it's just

 HW makes the asumptions

   Not true at all. There is a separate set of registers (at offset 0) which
copes with USB specifics, but CPPI 4.1 itself doesn't know about USB anything.
It's just the way the driver was written that it used both sets of registers but
this needs to be changed into more abstacted accesses to the USB-specific part,
to cope with it being different on different platfroms, like AM35x. The driver
as it was last posted, just needs rework now.

 but nevertheless, the IP can be, and in fact is,
 used with many different DMA engines and driver needs to cope with it.

What IP, CPPI 4.1 or MUSB?

 MUSB

 Current DMA abstraction is quite poor, for example there's no way to
 compile support for multiple DMA engines. Code also makes certain, IMO
 unnecessary, assumptions about the underlying DMA engine (abstraction is
 poor, as said above but it we could follow MUSB's programming guide when
 it comes to programming DMA transfers).

Don't know, I was quite content with the abstraction when writing CPPI 4.1
 driver for MUSB...

 look closer. The whole:

 if (is_cppi())
   foo();
 else if (is_inventra())
   bar();
 else if (is_omap_sdma())
   baz();

 is bogus.

   That part -- yes. There were attempt to get rid of this, but without changing
the DMA API. It was left halfway done after my only critical comment, IIRC. Will
we ever see the continuation of this effort?

 Considering all of the above, it's far better to use DMA engine and get
 rid of all the mess.

In my eyes, getting rid of the mess doesn't justify breaking the rules 
 that
 Russell formulated above.

 MUSB is no PCI, there is no single, standard interface to the DMA
 engine (unlike Synopsys' dwc-usb3 and dwc-usb2, where we don't use DMA
 engine), every DMA engine comes with its own set of registers, its own
 programming model and so forth.

   Same can be said about PCI where each bus master has its own programming i/f
-- so I didn't really dig this example.

WBR, Sergei

--
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 01/10] ARM: davinci: move private EDMA API to arm/common

Hi,

On Mon, Feb 04, 2013 at 08:54:17PM +0300, Sergei Shtylyov wrote:
  On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
  opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
  Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver.
 
  Granted, CPPI 4.1 makes some assumptions about the fact that it's
  handling USB tranfers,
 
 What CPPI 4.1 code makes this assumptions? MUSB DMA driver? Then it's 
  just
 
  HW makes the asumptions
 
Not true at all. There is a separate set of registers (at offset 0) which
 copes with USB specifics, but CPPI 4.1 itself doesn't know about USB anything.

CPPI 4.1 was made for USB transfers.

 It's just the way the driver was written that it used both sets of registers 
 but
 this needs to be changed into more abstacted accesses to the USB-specific 
 part,
 to cope with it being different on different platfroms, like AM35x. The driver
 as it was last posted, just needs rework now.

are you saying you will do the work ?

 Don't know, I was quite content with the abstraction when writing CPPI 
  4.1
  driver for MUSB...
 
  look closer. The whole:
 
  if (is_cppi())
  foo();
  else if (is_inventra())
  bar();
  else if (is_omap_sdma())
  baz();
 
  is bogus.
 
That part -- yes. There were attempt to get rid of this, but without 
 changing
 the DMA API. It was left halfway done after my only critical comment, IIRC. 
 Will
 we ever see the continuation of this effort?

patches are welcome

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

2013-02-04 Thread Russell King - ARM Linux

On Mon, Feb 04, 2013 at 06:47:12PM +0200, Felipe Balbi wrote:
 Hi,
 
 On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
 In my eyes, getting rid of the mess doesn't justify breaking the rules 
  that
  Russell formulated above.
 
 MUSB is no PCI, there is no single, standard interface to the DMA
 engine (unlike Synopsys' dwc-usb3 and dwc-usb2, where we don't use DMA
 engine), every DMA engine comes with its own set of registers, its own
 programming model and so forth.

Err, before you get too wrapped up in that argument... if you think there's
anything like a common hardware interface for DMA on PCI, you'd be wrong.
There isn't.

What there is is a bus protocol for it.  How the device decides to perform
DMA is up to the device; there's no standard register definitions across
all devices.  Yes, some classes have a standard register set (like USB,
and ATA) but others are totally device specific (eg, network chips).

However, on PCI, the DMA support is always integrated with the rest of
the device itself.  That is not the case here.

So, bringing PCI up into this discussion is totally irrelevant.  As I've
already explained, this was brought up in the _previous_ discussion as
a reason why _not_ to use the DMA engine API for this.

So, can we please leave PCI totally out of this?  It didn't belong here
2-3 years ago, and it sure enough doesn't belong here now.  It's nothing
but pure distraction.  And the more this goes on, the more I can see,
yet again, the CPPI 4.1 going nowhere at all.

As I can see it, there's nothing more to talk about.  The issue has been
extensively talked to death.  What it needs now is not _more_ talk, it
needs someone to actually go and _do_ something useful with it.

I realise that may be difficult given the mess that TI must still be in
internally since the upheaval of OMAP, but it sounds like there's a
different group needing this stuff to work...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/4] drivers: usb: start using the control module driver

* Felipe Balbi ba...@ti.com [130204 07:57]:
 Hi,
 
 On Fri, Feb 01, 2013 at 11:14:24AM -0800, Tony Lindgren wrote:
  * Felipe Balbi ba...@ti.com [130125 02:30]:
   Hi,
   
   On Fri, Jan 25, 2013 at 03:54:00PM +0530, Kishon Vijay Abraham I wrote:
Start using the control module driver for powering on the PHY and for
writing to the mailbox instead of writing to the control module
registers on their own.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 Documentation/devicetree/bindings/usb/omap-usb.txt |4 ++
 Documentation/devicetree/bindings/usb/usb-phy.txt  |7 +-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   13 
   
   I'm taking this patch but I'm leaving out the omap_hwmod_44xx_data.c
   change just to kill dependency. Can you send that single change as a
   separate patch which Tony can queue ?
  
  For the USB patches, please also leave out patches touching
  arch/arm/mach-omap2/devices.c. Those are almost guaranteed to
  cause pointless merge conflicts with other branches.
  
  I suggest you set up few immutable branches:
  
  1. Minimal platform_data changes for all your USB changes
  
  This should contain include/linux/platform_data changes and
  changes to arch/arm/*omap* so me and Paul can merge it in too
  to avoid merge conflicts.
  
  2. The rest of the driver/usb changes
  
  This can then be based on #1 branch above.
  
  3. Changes for the .dts files for Benoit
  
  These can be queued separately from #1 and #2 above.
 
 I'm done with all USB stuff for this merge window. The patches which I
 didn't take have no dependencies on any drivers/ part. You can easily
 queue this through your tree.

Sorry with a huge pile of USB patches being posted I have no idea at
this point which USB related patches for arch/arm/*omap* have no
dependencies to the USB driver changes.

So I suggest that you, Kishon and Roger figure it out and put together
a pull request for me against v3.8-rc6 for the patches I should merge.

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 v7 01/10] ARM: davinci: move private EDMA API to arm/common

2013-02-04 Thread Sergei Shtylyov

Hello.

On 02/04/2013 08:02 PM, Felipe Balbi wrote:

 On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
 opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
 Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver.

 Granted, CPPI 4.1 makes some assumptions about the fact that it's
 handling USB tranfers,

What CPPI 4.1 code makes this assumptions? MUSB DMA driver? Then it's 
 just

 HW makes the asumptions

Not true at all. There is a separate set of registers (at offset 0) which
 copes with USB specifics, but CPPI 4.1 itself doesn't know about USB 
 anything.

 CPPI 4.1 was made for USB transfers.

   Utter nonsense, CPPI 4.1 is hardware abstract DMA engine. It's used for
Ethernet transfers on out-of-tree platforms like mach-avalanche/.

 It's just the way the driver was written that it used both sets of registers 
 but
 this needs to be changed into more abstacted accesses to the USB-specific 
 part,
 to cope with it being different on different platfroms, like AM35x. The 
 driver
 as it was last posted, just needs rework now.

 are you saying you will do the work ?

   My efforts stopped to be funded by MV back in 2010. Hell, I'm not even
working in MV as I used to, hanging on the verge of my current contract being
terminated.

Don't know, I was quite content with the abstraction when writing CPPI 
 4.1
 driver for MUSB...

 look closer. The whole:

 if (is_cppi())
 foo();
 else if (is_inventra())
 bar();
 else if (is_omap_sdma())
 baz();

 is bogus.

That part -- yes. There were attempt to get rid of this, but without 
 changing
 the DMA API. It was left halfway done after my only critical comment, IIRC. 
 Will
 we ever see the continuation of this effort?

 patches are welcome

   There was a patch, it only needed comments addressed. I think the author was
Heikki Krogerus. As for me, my time is very limited, so be thankful even for
those scarce patches I'm sending out now -- I'm doing them in my copious free 
time.

WBR, Sergei

--
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/2] ARM: dts: OMAP3: Add GPMC controller

* Javier Martinez Canillas jav...@dowhile0.org [130204 04:00]:
 On Mon, Feb 4, 2013 at 11:36 AM, Florian Vaussard
  Great, the smsc911x was on my TODO list, I can cross it out :) BTW,
  do you have a public git for this, so I can test your work on my setup?
 
 
 Yes, it is the gpmc-smsc911x-wip branch on my github linux tree [1]
 
 That branch is Linus master tree + linux-omap/omap-for-v3.9/gpmc +
 linux-omap-dt/for_3.9/dts
 
 plus these patches:
 
 Javier Martinez Canillas (4):
   ARM: OMAP: gpmc-smsc911x: add DT dev node init function
   ARM: OMAP: gpmc: add support for gpmc-smsc911x child nodes
   ARM: dts: OMAP: Add an GPMC node for OMAP3
   ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support
 
 You can browse these patches here [2].
 
 With these patches I have ethernet working on my IGEPv2 but this board
 uses an OMAP GPIO pin as the smsc911x IRQ line, so it needs to set a
 mux pin (mcspi1_cs2.gpio_176 INPUT | MODE4) or it will fallback on
 poll mode.

Great, that's good news :)

 For some reasons I still couldn't figure out (I'm still learning about
 Device Trees) adding:
 
pinctrl = devm_pinctrl_get_select_default(pdev-dev);
 
 to the gpmc-smsc911x child node parse function (gpmc_smsc911x_init_dt)
 didn't have a functional effect and I had to initialize the defined
 pinctrl-single pins for the smsc911x in the omap3_pmx_core device node
 instead of pmc_smsc911x@0 as I do for other devices (mmc, uarts, etc).

Maybe this is related to the initcall ordering..
 
 So I just removed the devm_pinctrl_get_select_default() call in
 gpmc_smsc911x_init_dt() in for this RFC.
 
 I don't know if this is because arch/arm/mach-omap2/gpmc-smsc911x.c is
 not a real platform driver (is just a wrapper/helper function) and
 doesn't have a probe function.

..that function just initializes the pdata for smsc911x driver, and
should not be a driver. You need to add devm_pinctrl_get_select_default()
to the probe of smsc911x or the GPMC probe.
 
 Which brings me to the question if my approach of adding a binding for
 gpmc-smsc911x is correct or if we should extend/use the binding that
 already exist for smsc911x
 (Documentation/devicetree/bindings/net/smsc911x.txt).

We should use the existing smsc911x binding, then have a separate GPMC
binding for the GPMC driver.

Regards,

Tony 
 
 [1]: git://github.com/martinezjavier/linux.git
 [2]: https://github.com/martinezjavier/linux/commits/gpmc-smsc911x-wip
 [3]: http://omappedia.org/wiki/Bootloader_Project#SYSBOOT_Pins
--
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/7] ARM: OMAP2+: System timer updates

This series consists mainly of clean-ups for clockevents and
clocksource timers on OMAP2+ devices. The most significant change
in functionality comes from the 5th patch which is changing the
selection of the clocksource timer for OMAP3 and AM335x devices
when gptimers are used for clocksource. This change came about from
Vaibhav Bedia's series for AM335x [1]. See patch for more details on
the exact nature of the change.

Boot tested with and without  device-tree on OMAP2420 H4, OMAP3430 SDP,
OMAP3430 Beagle Board, OMAP4430 SDP and AM335x EVM (AM335x only
supports device-tree boot). Also boot tested boards with kernel boot
parameter clocksource=gp_timer.

This series is based upon ARM-SoC next branch.

V2 changes:
- Fixed bug in patch that updates clocksource and clockevents timer
  names to use the hwmod timer names (thanks Vaibhav Bedia!)
- Updated patch that removes the hard-coded ID test to return an error
  as soon as clk_set_parent fails instead of waiting for the end of the
  function.
- Fixed bug in patches that simplify system timer clock definitions
  and simplify system timer definitions that was prevent omap4/5
  boards from booting with kernel boot parameter clocksource=gp_timer.
- Updated changelog for patch simplify system timer definitions per
  feedback received from Igor.
- Added new patch to store the timer ID in the omap_dm_timer structure
  to clean-up the code.
- Added new patch to fix a sparse warning seen in ARM-SOC next.

[1] https://patchwork.kernel.org/patch/1921421/


Jon Hunter (7):
  ARM: OMAP2+: Fix selection of clockevent timer when using device-tree
  ARM: OMAP2+: Display correct system timer name
  ARM: OMAP2+: Remove hard-coded test on timer ID
  ARM: OMAP2+: Simplify system timer clock definitions
  ARM: OMAP2+: Simplify system timers definitions
  ARM: OMAP2+: Store ID of system timers in timer structure
  ARM: OMAP4+: Fix sparse warning in system timers

 arch/arm/mach-omap2/board-cm-t3517.c |2 +-
 arch/arm/mach-omap2/board-generic.c  |2 +-
 arch/arm/mach-omap2/common.h |3 +-
 arch/arm/mach-omap2/timer.c  |  121 +-
 4 files changed, 65 insertions(+), 63 deletions(-)

-- 
1.7.10.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 V2 1/7] ARM: OMAP2+: Fix selection of clockevent timer when using device-tree

Commit 9725f44 (ARM: OMAP: Add DT support for timer driver) added
device-tree support for selecting a clockevent timer by property.
However, the code is currently ignoring the property passed and
selecting the first available timer found. Hence, for the OMAP3 beagle
board timer-12 is not being selected as expected. Fix this problem
by ensuring the timer property is passed to omap_get_timer_dt().

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/timer.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 2822833..72c2ca1 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -227,7 +227,7 @@ static int __init omap_dm_timer_init_one(struct 
omap_dm_timer *timer,
int r = 0;
 
if (of_have_populated_dt()) {
-   np = omap_get_timer_dt(omap_timer_match, NULL);
+   np = omap_get_timer_dt(omap_timer_match, property);
if (!np)
return -ENODEV;
 
-- 
1.7.10.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 V2 3/7] ARM: OMAP2+: Remove hard-coded test on timer ID

Currently, when configuring the clock-events and clock-source timers
for OMAP2+ devices, we check whether the timer ID is 12 before
attempting to set the parent clock for the timer.

This test was added for OMAP3 general purpose devices (no security
features enabled) that a 12th timer available but unlike the other
timers only has a single functional clock source. Calling
clk_set_parent() for this 12th timer would always return an error
because there is only one choice for a parent clock. Therefore,
this hard-coded timer ID test was added.

To avoid this timer ID test, simply check to see if the timer's current
parent clock is the desired parent clock and only call clk_set_parent()
if this is not the case.

Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/timer.c |   25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 83118fb..ec2fb80 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -224,6 +224,7 @@ static int __init omap_dm_timer_init_one(struct 
omap_dm_timer *timer,
struct device_node *np;
struct omap_hwmod *oh;
struct resource irq, mem;
+   struct clk *src;
int r = 0;
 
if (of_have_populated_dt()) {
@@ -280,22 +281,22 @@ static int __init omap_dm_timer_init_one(struct 
omap_dm_timer *timer,
if (IS_ERR(timer-fclk))
return -ENODEV;
 
-   /* FIXME: Need to remove hard-coded test on timer ID */
-   if (gptimer_id != 12) {
-   struct clk *src;
-
-   src = clk_get(NULL, fck_source);
-   if (IS_ERR(src)) {
-   r = -EINVAL;
-   } else {
-   r = clk_set_parent(timer-fclk, src);
-   if (IS_ERR_VALUE(r))
-   pr_warn(%s: %s cannot set source\n,
-   __func__, oh-name);
+   src = clk_get(NULL, fck_source);
+   if (IS_ERR(src))
+   return -EINVAL;
+
+   if (clk_get_parent(timer-fclk) != src) {
+   r = clk_set_parent(timer-fclk, src);
+   if (IS_ERR_VALUE(r)) {
+   pr_warn(%s: %s cannot set source\n, __func__,
+   oh-name);
clk_put(src);
+   return r;
}
}
 
+   clk_put(src);
+
omap_hwmod_setup_one(oh_name);
omap_hwmod_enable(oh);
__omap_dm_timer_init_regs(timer);
-- 
1.7.10.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 V2 2/7] ARM: OMAP2+: Display correct system timer name

Currently on boot, when displaying the name of the gptimer used for
clockevents and clocksource timers, the timer ID is shown. However,
when booting with device-tree, the timer ID is not used to select a
gptimer but a timer property. Hence, it is possible that the timer
selected when booting with device-tree does not match the ID shown.
Therefore, instead display the HWMOD name of the gptimer and use
the HWMOD name as the name of clockevent and clocksource timer (if a
gptimer is used).

Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/timer.c |   24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 72c2ca1..83118fb 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -129,7 +129,6 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode 
mode,
 }
 
 static struct clock_event_device clockevent_gpt = {
-   .name   = gp_timer,
.features   = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
.rating = 300,
.set_next_event = omap2_gp_timer_set_next_event,
@@ -214,10 +213,11 @@ static u32 __init omap_dm_timer_get_errata(void)
 }
 
 static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
-   int gptimer_id,
-   const char *fck_source,
-   const char *property,
-   int posted)
+int gptimer_id,
+const char *fck_source,
+const char *property,
+const char **timer_name,
+int posted)
 {
char name[10]; /* 10 = sizeof(gptXX_Xck0) */
const char *oh_name;
@@ -254,6 +254,8 @@ static int __init omap_dm_timer_init_one(struct 
omap_dm_timer *timer,
if (!oh)
return -ENODEV;
 
+   *timer_name = oh-name;
+
if (!of_have_populated_dt()) {
r = omap_hwmod_get_resource_byname(oh, IORESOURCE_IRQ, NULL,
   irq);
@@ -327,7 +329,7 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
__omap_dm_timer_override_errata(clkev, OMAP_TIMER_ERRATA_I103_I767);
 
res = omap_dm_timer_init_one(clkev, gptimer_id, fck_source, property,
-OMAP_TIMER_POSTED);
+clockevent_gpt.name, OMAP_TIMER_POSTED);
BUG_ON(res);
 
omap2_gp_timer_irq.dev_id = clkev;
@@ -341,8 +343,8 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
3, /* Timer internal resynch latency */
0x);
 
-   pr_info(OMAP clockevent source: GPTIMER%d at %lu Hz\n,
-   gptimer_id, clkev.rate);
+   pr_info(OMAP clockevent source: %s at %lu Hz\n, clockevent_gpt.name,
+   clkev.rate);
 }
 
 /* Clocksource code */
@@ -359,7 +361,6 @@ static cycle_t clocksource_read_cycles(struct clocksource 
*cs)
 }
 
 static struct clocksource clocksource_gpt = {
-   .name   = gp_timer,
.rating = 300,
.read   = clocksource_read_cycles,
.mask   = CLOCKSOURCE_MASK(32),
@@ -449,6 +450,7 @@ static void __init omap2_gptimer_clocksource_init(int 
gptimer_id,
clksrc.errata = omap_dm_timer_get_errata();
 
res = omap_dm_timer_init_one(clksrc, gptimer_id, fck_source, NULL,
+clocksource_gpt.name,
 OMAP_TIMER_NONPOSTED);
BUG_ON(res);
 
@@ -461,8 +463,8 @@ static void __init omap2_gptimer_clocksource_init(int 
gptimer_id,
pr_err(Could not register clocksource %s\n,
clocksource_gpt.name);
else
-   pr_info(OMAP clocksource: GPTIMER%d at %lu Hz\n,
-   gptimer_id, clksrc.rate);
+   pr_info(OMAP clocksource: %s at %lu Hz\n,
+   clocksource_gpt.name, clksrc.rate);
 }
 
 #ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
-- 
1.7.10.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 V2 5/7] ARM: OMAP2+: Simplify system timers definitions

There is a lot of redundancy in the definitions for the various system
timers for OMAP2+ devices. For example, the omap3_am33xx_gptimer_timer_init()
function is the same as the omap3_gp_gptimer_timer_init() function and the
function omap4_sync32k_timer_init() can be re-used for OMAP5 devices.
Therefore, consolidate the definitions to simplify the code.

Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Igor Grinberg grinb...@compulab.co.il
---
 arch/arm/mach-omap2/board-cm-t3517.c |2 +-
 arch/arm/mach-omap2/board-generic.c  |2 +-
 arch/arm/mach-omap2/common.h |3 +--
 arch/arm/mach-omap2/timer.c  |   48 --
 4 files changed, 31 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-omap2/board-cm-t3517.c 
b/arch/arm/mach-omap2/board-cm-t3517.c
index 6a9529a..7c1ad68 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -297,6 +297,6 @@ MACHINE_START(CM_T3517, Compulab CM-T3517)
.handle_irq = omap3_intc_handle_irq,
.init_machine   = cm_t3517_init,
.init_late  = am35xx_init_late,
-   .init_time  = omap3_gp_gptimer_timer_init,
+   .init_time  = omap3_gptimer_timer_init,
.restart= omap3xxx_restart,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 2590463..dfd9f48 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -138,7 +138,7 @@ DT_MACHINE_START(AM33XX_DT, Generic AM33XX (Flattened 
Device Tree))
.init_irq   = omap_intc_of_init,
.handle_irq = omap3_intc_handle_irq,
.init_machine   = omap_generic_init,
-   .init_time  = omap3_am33xx_gptimer_timer_init,
+   .init_time  = omap3_gptimer_timer_init,
.dt_compat  = am33xx_boards_compat,
 MACHINE_END
 #endif
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index b435027..594ab3b 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -82,8 +82,7 @@ extern void omap2_init_common_infrastructure(void);
 extern void omap2_sync32k_timer_init(void);
 extern void omap3_sync32k_timer_init(void);
 extern void omap3_secure_sync32k_timer_init(void);
-extern void omap3_gp_gptimer_timer_init(void);
-extern void omap3_am33xx_gptimer_timer_init(void);
+extern void omap3_gptimer_timer_init(void);
 extern void omap4_local_timer_init(void);
 extern void omap5_realtime_timer_init(void);
 
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 4213bf4..1b99b41 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -160,6 +160,12 @@ static struct device_node * __init 
omap_get_timer_dt(struct of_device_id *match,
if (property  !of_get_property(np, property, NULL))
continue;
 
+   if (!property  (of_get_property(np, ti,timer-alwon, NULL) ||
+ of_get_property(np, ti,timer-dsp, NULL) ||
+ of_get_property(np, ti,timer-pwm, NULL) ||
+ of_get_property(np, ti,timer-secure, NULL)))
+   continue;
+
of_add_property(np, device_disabled);
return np;
}
@@ -435,13 +441,14 @@ static int __init __maybe_unused 
omap2_sync32k_clocksource_init(void)
 }
 
 static void __init omap2_gptimer_clocksource_init(int gptimer_id,
-   const char *fck_source)
+ const char *fck_source,
+ const char *property)
 {
int res;
 
clksrc.errata = omap_dm_timer_get_errata();
 
-   res = omap_dm_timer_init_one(clksrc, gptimer_id, fck_source, NULL,
+   res = omap_dm_timer_init_one(clksrc, gptimer_id, fck_source, property,
 clocksource_gpt.name,
 OMAP_TIMER_NONPOSTED);
BUG_ON(res);
@@ -538,49 +545,52 @@ static inline void __init realtime_counter_init(void)
 #endif
 
 #define OMAP_SYS_GP_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop,  \
-  clksrc_nr, clksrc_src)   \
+  clksrc_nr, clksrc_src, clksrc_prop)  \
 void __init omap##name##_gptimer_timer_init(void)  \
 {  \
omap_dmtimer_init();\
omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
-   omap2_gptimer_clocksource_init((clksrc_nr), clksrc_src);\
+   omap2_gptimer_clocksource_init((clksrc_nr), clksrc_src, \
+   clksrc_prop);   \
 }
 
 #define

[PATCH V2 7/7] ARM: OMAP4+: Fix sparse warning in system timers

Commit 6bb27d7 (ARM: delete struct sys_timer) changed the function
created by the macro OMAP_SYS_32K_TIMER_INIT from static void to void.
For OMAP4+ devices this created the following sparse warning ...

arch/arm/mach-omap2/timer.c:585:1: warning: symbol
'omap4_sync32k_timer_init' was not declared. Should it be static?

The function omap4_sync32k_timer_init() is not referenced outside of the
file timer.c and so make this function static.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/timer.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index c5770ff..a5f88b2 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -587,8 +587,8 @@ OMAP_SYS_GP_TIMER_INIT(3, 2, timer_sys_ck, NULL,
 #endif
 
 #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
-OMAP_SYS_32K_TIMER_INIT(4, 1, timer_32k_ck, ti,timer-alwon,
-   2, sys_clkin_ck, NULL);
+static OMAP_SYS_32K_TIMER_INIT(4, 1, timer_32k_ck, ti,timer-alwon,
+  2, sys_clkin_ck, NULL);
 #endif
 
 #ifdef CONFIG_ARCH_OMAP4
-- 
1.7.10.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 V2 6/7] ARM: OMAP2+: Store ID of system timers in timer structure

Currently, the timer ID is being passed to the function
omap_dm_timer_init_one(). Instead of passing the ID separately, store it
in the omap_dm_timer structure, that is also passed, and access the ID
from this structure.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/timer.c |   11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 1b99b41..c5770ff 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -210,7 +210,6 @@ static u32 __init omap_dm_timer_get_errata(void)
 }
 
 static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
-int gptimer_id,
 const char *fck_source,
 const char *property,
 const char **timer_name,
@@ -241,10 +240,10 @@ static int __init omap_dm_timer_init_one(struct 
omap_dm_timer *timer,
 
of_node_put(np);
} else {
-   if (omap_dm_timer_reserve_systimer(gptimer_id))
+   if (omap_dm_timer_reserve_systimer(timer-id))
return -ENODEV;
 
-   sprintf(name, timer%d, gptimer_id);
+   sprintf(name, timer%d, timer-id);
oh_name = name;
}
 
@@ -317,6 +316,7 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
 {
int res;
 
+   clkev.id = gptimer_id;
clkev.errata = omap_dm_timer_get_errata();
 
/*
@@ -326,7 +326,7 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
 */
__omap_dm_timer_override_errata(clkev, OMAP_TIMER_ERRATA_I103_I767);
 
-   res = omap_dm_timer_init_one(clkev, gptimer_id, fck_source, property,
+   res = omap_dm_timer_init_one(clkev, fck_source, property,
 clockevent_gpt.name, OMAP_TIMER_POSTED);
BUG_ON(res);
 
@@ -446,9 +446,10 @@ static void __init omap2_gptimer_clocksource_init(int 
gptimer_id,
 {
int res;
 
+   clksrc.id = gptimer_id;
clksrc.errata = omap_dm_timer_get_errata();
 
-   res = omap_dm_timer_init_one(clksrc, gptimer_id, fck_source, property,
+   res = omap_dm_timer_init_one(clksrc, fck_source, property,
 clocksource_gpt.name,
 OMAP_TIMER_NONPOSTED);
BUG_ON(res);
-- 
1.7.10.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 V2 4/7] ARM: OMAP2+: Simplify system timer clock definitions

In commit c59b537 (ARM: OMAP2+: Simplify dmtimer clock aliases), new
clock aliases for dmtimers were added to simplify the code. These clock
aliases can also be used when configuring the system timers and allow us
to remove the current definitions, simplifying the code.

Please note that for OMAP4/5 devices (unlike OMAP2/3 devices), there is
no clock alias for timer_sys_ck with NULL as the device name. Therefore
we still need to use the alias sys_clkin_ck for these devices.

Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/timer.c |   37 ++---
 1 file changed, 14 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index ec2fb80..4213bf4 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -57,15 +57,6 @@
 #include common.h
 #include powerdomain.h
 
-/* Parent clocks, eventually these will come from the clock framework */
-
-#define OMAP2_MPU_SOURCE   sys_ck
-#define OMAP3_MPU_SOURCE   OMAP2_MPU_SOURCE
-#define OMAP4_MPU_SOURCE   sys_clkin_ck
-#define OMAP2_32K_SOURCE   func_32k_ck
-#define OMAP3_32K_SOURCE   omap_32k_fck
-#define OMAP4_32K_SOURCE   sys_32k_ck
-
 #define REALTIME_COUNTER_BASE  0x48243200
 #define INCREMENTER_NUMERATOR_OFFSET   0x10
 #define INCREMENTER_DENUMERATOR_RELOAD_OFFSET  0x14
@@ -569,27 +560,27 @@ void __init omap##name##_sync32k_timer_init(void) 
\
 }
 
 #ifdef CONFIG_ARCH_OMAP2
-OMAP_SYS_32K_TIMER_INIT(2, 1, OMAP2_32K_SOURCE, ti,timer-alwon,
-   2, OMAP2_MPU_SOURCE);
+OMAP_SYS_32K_TIMER_INIT(2, 1, timer_32k_ck, ti,timer-alwon,
+   2, timer_sys_ck);
 #endif /* CONFIG_ARCH_OMAP2 */
 
 #ifdef CONFIG_ARCH_OMAP3
-OMAP_SYS_32K_TIMER_INIT(3, 1, OMAP3_32K_SOURCE, ti,timer-alwon,
-   2, OMAP3_MPU_SOURCE);
-OMAP_SYS_32K_TIMER_INIT(3_secure, 12, OMAP3_32K_SOURCE, ti,timer-secure,
-   2, OMAP3_MPU_SOURCE);
-OMAP_SYS_GP_TIMER_INIT(3_gp, 1, OMAP3_MPU_SOURCE, ti,timer-alwon,
-  2, OMAP3_MPU_SOURCE);
+OMAP_SYS_32K_TIMER_INIT(3, 1, timer_32k_ck, ti,timer-alwon,
+   2, timer_sys_ck);
+OMAP_SYS_32K_TIMER_INIT(3_secure, 12, secure_32k_fck, ti,timer-secure,
+   2, timer_sys_ck);
+OMAP_SYS_GP_TIMER_INIT(3_gp, 1, timer_sys_ck, ti,timer-alwon,
+  2, timer_sys_ck);
 #endif /* CONFIG_ARCH_OMAP3 */
 
 #ifdef CONFIG_SOC_AM33XX
-OMAP_SYS_GP_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, ti,timer-alwon,
-  2, OMAP4_MPU_SOURCE);
+OMAP_SYS_GP_TIMER_INIT(3_am33xx, 1, timer_sys_ck, ti,timer-alwon,
+  2, timer_sys_ck);
 #endif /* CONFIG_SOC_AM33XX */
 
 #ifdef CONFIG_ARCH_OMAP4
-OMAP_SYS_32K_TIMER_INIT(4, 1, OMAP4_32K_SOURCE, ti,timer-alwon,
-   2, OMAP4_MPU_SOURCE);
+OMAP_SYS_32K_TIMER_INIT(4, 1, timer_32k_ck, ti,timer-alwon,
+   2, sys_clkin_ck);
 #ifdef CONFIG_LOCAL_TIMERS
 static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, OMAP44XX_LOCAL_TWD_BASE, 29);
 void __init omap4_local_timer_init(void)
@@ -618,8 +609,8 @@ void __init omap4_local_timer_init(void)
 #endif /* CONFIG_ARCH_OMAP4 */
 
 #ifdef CONFIG_SOC_OMAP5
-OMAP_SYS_32K_TIMER_INIT(5, 1, OMAP4_32K_SOURCE, ti,timer-alwon,
-   2, OMAP4_MPU_SOURCE);
+OMAP_SYS_32K_TIMER_INIT(5, 1, timer_32k_ck, ti,timer-alwon,
+   2, sys_clkin_ck);
 void __init omap5_realtime_timer_init(void)
 {
int err;
-- 
1.7.10.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

Re: [PATCH 2/2] ARM: OMAP2: Fix GPMC memory initialisation

* Jon Hunter jon-hun...@ti.com [130204 07:09]:
 
 On 02/02/2013 12:11 PM, Tony Lindgren wrote:
  * Jon Hunter jon-hun...@ti.com [130201 17:25]:
 
  On 02/01/2013 03:51 PM, Tony Lindgren wrote:
 
  How about let's fix this properly to start with so we don't add
  more blockers moving this code to drivers/bus?
 
  Looks like gpmc_mem_init() gets called from gpmc_probe() so
  we can pass that information in pdev.
 
  I wondered if you would suggest that ;-)
  
  :)
   
  I definitely can and it is probably best. Things like this become
  painful when we move to device-tree. We really need a generic way for
  passing stuff like this to drivers for omap. Our options are auxdata or
  bus notifiers. I am wondering whether we can plug pdata in the
  omap_device bus notifier for device-tree. Let me know if you have any
  thoughts.
  
  Hmm but in this case can't you just do it based on the compatible
  flag? For legacy systems we also need to pass it in pdata.
 
 This is a boot-time configuration. So really you need to read the
 control status register at boot and then determine the mapping. We could
 store the address of the control status read in the pdata, but I think
 that is a bit of a hack.

Ah right. Well once we have Haojian's generic pinconf patches merged for
pinctrl-single, we can set up the CONTROL_STATUS register as a
pinctrl-single,bits register and query the SYSBOOT_3 pin value directly
from the driver.

AFAIK SYSBOOT_n values reflect the boot time values of the actual SYSBOOT
pins, so using generic pinconf there makes sense. But this of course should
be checked.
 
  Regarding omap_device, we should find a way to keep the dependencies
  between drivers and the bus code down to minimum. So ideally things
  like this would be only done using just the compatible flag. But the
  pdata we cannot remove quite yet.
 
 Agree. However, there are several drivers today (gpio, dmtimer, mmc,
 serial, dss, etc), that make use of a function pointer to
 omap_pm_get_dev_context_loss_count() to determine when the peripheral's
 state has been lost. When booting with DT this function pointer is not
 populated and so with DT we currently have no way to determine this. I
 see this as a blocker to migrating completely to DT. Ideally we would
 find a way for RPM to handle this and remove the function pointer.
 However, right now we still need a generic way to pass this type of
 platform data to drivers.

Yeah pinconf generic won't help us with the legacy boot.

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 V2 3/7] ARM: OMAP2+: Remove hard-coded test on timer ID

2013-02-04 Thread Russell King - ARM Linux

On Mon, Feb 04, 2013 at 11:43:02AM -0600, Jon Hunter wrote:
 @@ -280,22 +281,22 @@ static int __init omap_dm_timer_init_one(struct 
 omap_dm_timer *timer,
   if (IS_ERR(timer-fclk))
   return -ENODEV;
  
 - /* FIXME: Need to remove hard-coded test on timer ID */
 - if (gptimer_id != 12) {
 - struct clk *src;
 -
 - src = clk_get(NULL, fck_source);
 - if (IS_ERR(src)) {
 - r = -EINVAL;
 - } else {
 - r = clk_set_parent(timer-fclk, src);
 - if (IS_ERR_VALUE(r))
 - pr_warn(%s: %s cannot set source\n,
 - __func__, oh-name);
 + src = clk_get(NULL, fck_source);
 + if (IS_ERR(src))
 + return -EINVAL;

This should be:
return PTR_ERR(src);

and should've been there previously...
--
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/7] ARM: OMAP2+: System timer updates


On 02/04/2013 11:42 AM, Jon Hunter wrote:
 This series consists mainly of clean-ups for clockevents and
 clocksource timers on OMAP2+ devices. The most significant change
 in functionality comes from the 5th patch which is changing the
 selection of the clocksource timer for OMAP3 and AM335x devices
 when gptimers are used for clocksource. This change came about from
 Vaibhav Bedia's series for AM335x [1]. See patch for more details on
 the exact nature of the change.
 
 Boot tested with and without  device-tree on OMAP2420 H4, OMAP3430 SDP,
 OMAP3430 Beagle Board, OMAP4430 SDP and AM335x EVM (AM335x only
 supports device-tree boot). Also boot tested boards with kernel boot
 parameter clocksource=gp_timer.
 
 This series is based upon ARM-SoC next branch.
 
 V2 changes:
 - Fixed bug in patch that updates clocksource and clockevents timer
   names to use the hwmod timer names (thanks Vaibhav Bedia!)
 - Updated patch that removes the hard-coded ID test to return an error
   as soon as clk_set_parent fails instead of waiting for the end of the
   function.
 - Fixed bug in patches that simplify system timer clock definitions
   and simplify system timer definitions that was prevent omap4/5
   boards from booting with kernel boot parameter clocksource=gp_timer.
 - Updated changelog for patch simplify system timer definitions per
   feedback received from Igor.
 - Added new patch to store the timer ID in the omap_dm_timer structure
   to clean-up the code.
 - Added new patch to fix a sparse warning seen in ARM-SOC next.
 
 [1] https://patchwork.kernel.org/patch/1921421/
 
 
 Jon Hunter (7):
   ARM: OMAP2+: Fix selection of clockevent timer when using device-tree

Ugh, sorry something got screwed up here. This was not meant to be
included and I am missing another patch. Will resend this series.

Jon
--
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 3/7] ARM: OMAP2+: Remove hard-coded test on timer ID


On 02/04/2013 11:46 AM, Russell King - ARM Linux wrote:
 On Mon, Feb 04, 2013 at 11:43:02AM -0600, Jon Hunter wrote:
 @@ -280,22 +281,22 @@ static int __init omap_dm_timer_init_one(struct 
 omap_dm_timer *timer,
  if (IS_ERR(timer-fclk))
  return -ENODEV;
  
 -/* FIXME: Need to remove hard-coded test on timer ID */
 -if (gptimer_id != 12) {
 -struct clk *src;
 -
 -src = clk_get(NULL, fck_source);
 -if (IS_ERR(src)) {
 -r = -EINVAL;
 -} else {
 -r = clk_set_parent(timer-fclk, src);
 -if (IS_ERR_VALUE(r))
 -pr_warn(%s: %s cannot set source\n,
 -__func__, oh-name);
 +src = clk_get(NULL, fck_source);
 +if (IS_ERR(src))
 +return -EINVAL;
 
 This should be:
   return PTR_ERR(src);
 
 and should've been there previously...

Thanks for the catch. I will include this and resend.

Cheers
Jon

--
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 v3 2/2] drivers: net:ethernet: cpsw: add support for VLAN

2013-02-04 Thread David Miller

From: Mugunthan V N mugunthan...@ti.com
Date: Fri, 1 Feb 2013 00:33:20 +0530

 diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
 b/Documentation/devicetree/bindings/net/cpsw.txt
 index 6ddd028..99696bf 100644
 --- a/Documentation/devicetree/bindings/net/cpsw.txt
 +++ b/Documentation/devicetree/bindings/net/cpsw.txt
 @@ -24,6 +24,8 @@ Required properties:
  Optional properties:
  - ti,hwmods  : Must be cpgmac0
  - no_bd_ram  : Must be 0 or 1
 +- default_vlan   : Specifies Default VLAN for non tagged packets
 +   ALE processing
  
  Note: ti,hwmods field is used to fetch the base address and irq
  resources from TI, omap hwmod data base during device registration.

You guys have to get away from this idea that you can basically pepper
devicetree bindings with all sorts of random behavioral knobs like
this, it's terrible.

Make this an ethtool configurable entity or similar, and don't even
think about adding a module parameter.
--
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/2] ARM: dts: OMAP3: Add GPMC controller

2013-02-04 Thread Javier Martinez Canillas

On Mon, Feb 4, 2013 at 6:32 PM, Tony Lindgren t...@atomide.com wrote:
 * Javier Martinez Canillas jav...@dowhile0.org [130204 04:00]:
 On Mon, Feb 4, 2013 at 11:36 AM, Florian Vaussard
  Great, the smsc911x was on my TODO list, I can cross it out :) BTW,
  do you have a public git for this, so I can test your work on my setup?
 

 Yes, it is the gpmc-smsc911x-wip branch on my github linux tree [1]

 That branch is Linus master tree + linux-omap/omap-for-v3.9/gpmc +
 linux-omap-dt/for_3.9/dts

 plus these patches:

 Javier Martinez Canillas (4):
   ARM: OMAP: gpmc-smsc911x: add DT dev node init function
   ARM: OMAP: gpmc: add support for gpmc-smsc911x child nodes
   ARM: dts: OMAP: Add an GPMC node for OMAP3
   ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support

 You can browse these patches here [2].

 With these patches I have ethernet working on my IGEPv2 but this board
 uses an OMAP GPIO pin as the smsc911x IRQ line, so it needs to set a
 mux pin (mcspi1_cs2.gpio_176 INPUT | MODE4) or it will fallback on
 poll mode.

 Great, that's good news :)


it's a start at least :-)

 For some reasons I still couldn't figure out (I'm still learning about
 Device Trees) adding:

pinctrl = devm_pinctrl_get_select_default(pdev-dev);

 to the gpmc-smsc911x child node parse function (gpmc_smsc911x_init_dt)
 didn't have a functional effect and I had to initialize the defined
 pinctrl-single pins for the smsc911x in the omap3_pmx_core device node
 instead of pmc_smsc911x@0 as I do for other devices (mmc, uarts, etc).

 Maybe this is related to the initcall ordering..


I don't think so since I added the gpmc@6e00 device node as the
last child node for ocp in omap3.dtsi. So, is way after omap3_pmx_core
child node is defined.

Btw, there is a way to specify the initialization order or the
dependencies between device nodes (e.g: gpmc depends on
omap3_pmx_core) or is just because of the position inside the DT?

 So I just removed the devm_pinctrl_get_select_default() call in
 gpmc_smsc911x_init_dt() in for this RFC.

 I don't know if this is because arch/arm/mach-omap2/gpmc-smsc911x.c is
 not a real platform driver (is just a wrapper/helper function) and
 doesn't have a probe function.

 ..that function just initializes the pdata for smsc911x driver, and
 should not be a driver. You need to add devm_pinctrl_get_select_default()
 to the probe of smsc911x or the GPMC probe.


Yes, that's what I meant. In that case I would have something like
this on my board dts:

gpmc {
pinctrl-names = default;
pinctrl-0 = smsc911x_pins;
gpmc_smsc911x@0 {
gpmc,cs = 5; /* IGEP2_SMSC911X_CS */
gpmc,gpio_irq = 176; /* IGEP2_SMSC911X_GPIO */
gpmc,flags = 18; /* SMSC911X_USE_32BIT | 
SMSC911X_SAVE_MAC_ADDRESS */
vmmc-supply = vddvario;
vmmc_aux-supply = vdd33a;
  };
};

Are you ok with tha approach?

Certainly is better than initializing in omap3_pmx_core node but still
is not consistent with other devices where the pinctrl pins are
defined inside the node of the device that requires them.

 Which brings me to the question if my approach of adding a binding for
 gpmc-smsc911x is correct or if we should extend/use the binding that
 already exist for smsc911x
 (Documentation/devicetree/bindings/net/smsc911x.txt).

 We should use the existing smsc911x binding, then have a separate GPMC
 binding for the GPMC driver.


You mean a binding for GPMC or a binding for gpmc-smsc911x?

I don't think that we can use the smsc911x binding directly since
gpmc_smsc911x_init() not only initializes the platform data but also
does some setup such as requesting a memory range for a specific chip
select (gpmc_cs_request), claiming a GPIO and configuring as input
(gpio_request_one), etc.

You can't just calculate the I/O space address for the GPMC cs your
peripheral is connected to and set it on the reg property of the
current smsc911x binding, right?. The same can be said for the nic
IRQ.

Or did I get wrong?

 Regards,

 Tony


Thanks a lot and best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM:omap2: using strlcpy instead of strncpy

* Peter Ujfalusi peter.ujfal...@ti.com [130204 01:04]:
 Hi Tony,
 
 On 02/01/2013 11:45 PM, Tony Lindgren wrote:
  * Chen Gang gang.c...@asianux.com [130130 03:50]:
 
the fields must be null-terminated:
the caller may use it as null-terminted string, next.
  
  Added Peter to cc on this one too, it's best that he queues
  all the twl changes.
 
 I can create a branch for you in our gitorious tree
 (git://gitorious.org/omap-audio/linux-audio.git) for this patch. But I think
 for now it would be best if you could take this via linux-omap (the file is
 under arch/arm/mach-omap2 anyways)

OK thanks I'll apply with your ack to omap-for-v3.9/fixes-noncritical.

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/2] ARM: OMAP2: Fix GPMC memory initialisation


On 02/04/2013 11:45 AM, Tony Lindgren wrote:
 * Jon Hunter jon-hun...@ti.com [130204 07:09]:

 On 02/02/2013 12:11 PM, Tony Lindgren wrote:
 * Jon Hunter jon-hun...@ti.com [130201 17:25]:

 On 02/01/2013 03:51 PM, Tony Lindgren wrote:

 How about let's fix this properly to start with so we don't add
 more blockers moving this code to drivers/bus?

 Looks like gpmc_mem_init() gets called from gpmc_probe() so
 we can pass that information in pdev.

 I wondered if you would suggest that ;-)

 :)
  
 I definitely can and it is probably best. Things like this become
 painful when we move to device-tree. We really need a generic way for
 passing stuff like this to drivers for omap. Our options are auxdata or
 bus notifiers. I am wondering whether we can plug pdata in the
 omap_device bus notifier for device-tree. Let me know if you have any
 thoughts.

 Hmm but in this case can't you just do it based on the compatible
 flag? For legacy systems we also need to pass it in pdata.

 This is a boot-time configuration. So really you need to read the
 control status register at boot and then determine the mapping. We could
 store the address of the control status read in the pdata, but I think
 that is a bit of a hack.
 
 Ah right. Well once we have Haojian's generic pinconf patches merged for
 pinctrl-single, we can set up the CONTROL_STATUS register as a
 pinctrl-single,bits register and query the SYSBOOT_3 pin value directly
 from the driver.
 
 AFAIK SYSBOOT_n values reflect the boot time values of the actual SYSBOOT
 pins, so using generic pinconf there makes sense. But this of course should
 be checked.

Not sure I am a fan of that idea. It is possible the pins could be
re-used as GPIOs after reset. Given that the state at reset is latched
in a register, it is best just to read the register directly.

 Regarding omap_device, we should find a way to keep the dependencies
 between drivers and the bus code down to minimum. So ideally things
 like this would be only done using just the compatible flag. But the
 pdata we cannot remove quite yet.

 Agree. However, there are several drivers today (gpio, dmtimer, mmc,
 serial, dss, etc), that make use of a function pointer to
 omap_pm_get_dev_context_loss_count() to determine when the peripheral's
 state has been lost. When booting with DT this function pointer is not
 populated and so with DT we currently have no way to determine this. I
 see this as a blocker to migrating completely to DT. Ideally we would
 find a way for RPM to handle this and remove the function pointer.
 However, right now we still need a generic way to pass this type of
 platform data to drivers.
 
 Yeah pinconf generic won't help us with the legacy boot.

Right. I view all this sort of thing as system-level device information
that some drivers may need. It does not seem that we have a good way to
handle that at the moment. Any ideas?

Jon
--
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/2] ARM: OMAP2: Fix GPMC memory initialisation

* Jon Hunter jon-hun...@ti.com [130204 10:49]:
 On 02/04/2013 11:45 AM, Tony Lindgren wrote:
  
  AFAIK SYSBOOT_n values reflect the boot time values of the actual SYSBOOT
  pins, so using generic pinconf there makes sense. But this of course should
  be checked.
 
 Not sure I am a fan of that idea. It is possible the pins could be
 re-used as GPIOs after reset. Given that the state at reset is latched
 in a register, it is best just to read the register directly.

Yes the physical SYSBOOT pins can be reused as GPIO, but that's are already
handled by the padconf and GPIO registers. This is a different register
showing the boot time pin values for some pins. So it makes sense to use
generic pinconf to make the pin values available to the client drivers
as needed.

The advantage doing it this way is that we don't need to export any omap
custom functions to the drivers from the SCM driver. This way we need zero
platform glue code, and can deal with it directly in the drivers in a
generic way. And all we need to do is just need to map the SoC specific
SYSBOOT pin register in the .dts files.

It may also make sense to export DEVICETYPE this way. At least early omaps
had the GP vs HS mode configured by pulls on some pins during the boot time.
So those bits too may reflect actual physical pins during the boot time
configured by the efuse settings?

  Regarding omap_device, we should find a way to keep the dependencies
  between drivers and the bus code down to minimum. So ideally things
  like this would be only done using just the compatible flag. But the
  pdata we cannot remove quite yet.
 
  Agree. However, there are several drivers today (gpio, dmtimer, mmc,
  serial, dss, etc), that make use of a function pointer to
  omap_pm_get_dev_context_loss_count() to determine when the peripheral's
  state has been lost. When booting with DT this function pointer is not
  populated and so with DT we currently have no way to determine this. I
  see this as a blocker to migrating completely to DT. Ideally we would
  find a way for RPM to handle this and remove the function pointer.
  However, right now we still need a generic way to pass this type of
  platform data to drivers.
  
  Yeah pinconf generic won't help us with the legacy boot.
 
 Right. I view all this sort of thing as system-level device information
 that some drivers may need. It does not seem that we have a good way to
 handle that at the moment. Any ideas?

I suggest just passing it in in pdata for now for the legacy boot. Then
I suggest we make what we can generic with pinconf in the long run.

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 v7 01/10] ARM: davinci: move private EDMA API to arm/common

2013-02-04 Thread Cyril Chemparathy

On 02/04/2013 12:02 PM, Felipe Balbi wrote:

Hi,

On Mon, Feb 04, 2013 at 08:54:17PM +0300, Sergei Shtylyov wrote:

On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:

opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1,
Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver.

Granted, CPPI 4.1 makes some assumptions about the fact that it's
handling USB tranfers,

What CPPI 4.1 code makes this assumptions? MUSB DMA driver? Then it's just

HW makes the asumptions

Not true at all. There is a separate set of registers (at offset 0) which
copes with USB specifics, but CPPI 4.1 itself doesn't know about USB anything.

CPPI 4.1 was made for USB transfers.

I have been dealing with CPPI hardware on KeyStone platforms (CPPI 4.2).
Our experiences with this DMA hardware may help with CPPI 4.1 on
earlier generations.

CPPI 4.2 serves as a truly common interface to a number of hardware
blocks on KeyStone SoCs - including Ethernet, RapidIO, Crypto
accelerators, and a bunch of other accelerator thingies. Given the
commonality across subsystems, we've built a shared CPPI 4.2 DMA-Engine
implementation. You can take a sneak peek at this implementation at [1].

Based on our experience with fitting multiple subsystems on top of this
DMA-Engine driver, I must say that the DMA-Engine interface has proven
to be a less than ideal fit for the network driver use case.

The first problem is that the DMA-Engine interface expects to push
completed traffic up into the upper layer as a part of its callback.
This doesn't fit cleanly with NAPI, which expects to pull completed
traffic from below in the NAPI poll. We've somehow kludged together a
solution around this, but it isn't very elegant.

The second problem is one of binding fixed DMA resources to fixed users.
AFAICT, the stock DMA-Engine mechanism works best when one DMA
resource is as good as any other. To get over this problem, we've added
support for named channels, and drivers specifically request for a DMA
resource by name. Again, this is less than ideal.

We found that virtio devices offer a more elegant solution to this
problem. First, the virtqueue interface is a much better fit into NAPI
(callback -- napi schedule, napi poll -- get_buf), and this eliminates
the need for aforementioned kludges in the code. Second, the virtio
device infrastructure nicely uses the device model to solve the problem
of binding DMA users to specific DMA resources.

These patches haven't (yet) been posted on the MLs, but you can peek at
[2]. While we are on the topic, I'd certainly appreciate feedback on
the concept of using virtqueues as an interface to peripheral
independent packet oriented DMA hardware. :-)

Cheers
-- Cyril

[1] -
http://arago-project.org/git/projects/?p=linux-keystone.git;a=shortlog;h=refs/heads/rebuild/23-drivers-dmaengine
[2] -
http://arago-project.org/git/projects/?p=linux-keystone.git;a=shortlog;h=refs/heads/rebuild/21-drivers-virtio

--
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/2] ARM: OMAP2: Fix GPMC memory initialisation


On 02/04/2013 01:15 PM, Tony Lindgren wrote:
 * Jon Hunter jon-hun...@ti.com [130204 10:49]:
 On 02/04/2013 11:45 AM, Tony Lindgren wrote:

 AFAIK SYSBOOT_n values reflect the boot time values of the actual SYSBOOT
 pins, so using generic pinconf there makes sense. But this of course should
 be checked.

 Not sure I am a fan of that idea. It is possible the pins could be
 re-used as GPIOs after reset. Given that the state at reset is latched
 in a register, it is best just to read the register directly.
 
 Yes the physical SYSBOOT pins can be reused as GPIO, but that's are already
 handled by the padconf and GPIO registers. This is a different register
 showing the boot time pin values for some pins. So it makes sense to use
 generic pinconf to make the pin values available to the client drivers
 as needed.
 
 The advantage doing it this way is that we don't need to export any omap
 custom functions to the drivers from the SCM driver. This way we need zero
 platform glue code, and can deal with it directly in the drivers in a
 generic way. And all we need to do is just need to map the SoC specific
 SYSBOOT pin register in the .dts files.

I see what you are saying exporting the state in control_status register
via the pinconf. That could work.

 It may also make sense to export DEVICETYPE this way. At least early omaps
 had the GP vs HS mode configured by pulls on some pins during the boot time.
 So those bits too may reflect actual physical pins during the boot time
 configured by the efuse settings?

I *believe* that was only omap1.

 Regarding omap_device, we should find a way to keep the dependencies
 between drivers and the bus code down to minimum. So ideally things
 like this would be only done using just the compatible flag. But the
 pdata we cannot remove quite yet.

 Agree. However, there are several drivers today (gpio, dmtimer, mmc,
 serial, dss, etc), that make use of a function pointer to
 omap_pm_get_dev_context_loss_count() to determine when the peripheral's
 state has been lost. When booting with DT this function pointer is not
 populated and so with DT we currently have no way to determine this. I
 see this as a blocker to migrating completely to DT. Ideally we would
 find a way for RPM to handle this and remove the function pointer.
 However, right now we still need a generic way to pass this type of
 platform data to drivers.

 Yeah pinconf generic won't help us with the legacy boot.

 Right. I view all this sort of thing as system-level device information
 that some drivers may need. It does not seem that we have a good way to
 handle that at the moment. Any ideas?
 
 I suggest just passing it in in pdata for now for the legacy boot. Then
 I suggest we make what we can generic with pinconf in the long run.

I don't see why we would want to export a function pointer to
omap_pm_get_dev_context_loss_count() with pinconf. Have we got our wires
crossed here?

Jon
--
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 V3 1/7] ARM: OMAP2+: Display correct system timer name

Currently on boot, when displaying the name of the gptimer used for
clockevents and clocksource timers, the timer ID is shown. However,
when booting with device-tree, the timer ID is not used to select a
gptimer but a timer property. Hence, it is possible that the timer
selected when booting with device-tree does not match the ID shown.
Therefore, instead display the HWMOD name of the gptimer and use
the HWMOD name as the name of clockevent and clocksource timer (if a
gptimer is used).

Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/timer.c |   24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 72c2ca1..83118fb 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -129,7 +129,6 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode 
mode,
 }
 
 static struct clock_event_device clockevent_gpt = {
-   .name   = gp_timer,
.features   = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
.rating = 300,
.set_next_event = omap2_gp_timer_set_next_event,
@@ -214,10 +213,11 @@ static u32 __init omap_dm_timer_get_errata(void)
 }
 
 static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
-   int gptimer_id,
-   const char *fck_source,
-   const char *property,
-   int posted)
+int gptimer_id,
+const char *fck_source,
+const char *property,
+const char **timer_name,
+int posted)
 {
char name[10]; /* 10 = sizeof(gptXX_Xck0) */
const char *oh_name;
@@ -254,6 +254,8 @@ static int __init omap_dm_timer_init_one(struct 
omap_dm_timer *timer,
if (!oh)
return -ENODEV;
 
+   *timer_name = oh-name;
+
if (!of_have_populated_dt()) {
r = omap_hwmod_get_resource_byname(oh, IORESOURCE_IRQ, NULL,
   irq);
@@ -327,7 +329,7 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
__omap_dm_timer_override_errata(clkev, OMAP_TIMER_ERRATA_I103_I767);
 
res = omap_dm_timer_init_one(clkev, gptimer_id, fck_source, property,
-OMAP_TIMER_POSTED);
+clockevent_gpt.name, OMAP_TIMER_POSTED);
BUG_ON(res);
 
omap2_gp_timer_irq.dev_id = clkev;
@@ -341,8 +343,8 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
3, /* Timer internal resynch latency */
0x);
 
-   pr_info(OMAP clockevent source: GPTIMER%d at %lu Hz\n,
-   gptimer_id, clkev.rate);
+   pr_info(OMAP clockevent source: %s at %lu Hz\n, clockevent_gpt.name,
+   clkev.rate);
 }
 
 /* Clocksource code */
@@ -359,7 +361,6 @@ static cycle_t clocksource_read_cycles(struct clocksource 
*cs)
 }
 
 static struct clocksource clocksource_gpt = {
-   .name   = gp_timer,
.rating = 300,
.read   = clocksource_read_cycles,
.mask   = CLOCKSOURCE_MASK(32),
@@ -449,6 +450,7 @@ static void __init omap2_gptimer_clocksource_init(int 
gptimer_id,
clksrc.errata = omap_dm_timer_get_errata();
 
res = omap_dm_timer_init_one(clksrc, gptimer_id, fck_source, NULL,
+clocksource_gpt.name,
 OMAP_TIMER_NONPOSTED);
BUG_ON(res);
 
@@ -461,8 +463,8 @@ static void __init omap2_gptimer_clocksource_init(int 
gptimer_id,
pr_err(Could not register clocksource %s\n,
clocksource_gpt.name);
else
-   pr_info(OMAP clocksource: GPTIMER%d at %lu Hz\n,
-   gptimer_id, clksrc.rate);
+   pr_info(OMAP clocksource: %s at %lu Hz\n,
+   clocksource_gpt.name, clksrc.rate);
 }
 
 #ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
-- 
1.7.10.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 V3 0/7] ARM: OMAP2+: System timer updates

This series consists mainly of clean-ups for clockevents and
clocksource timers on OMAP2+ devices. The most significant change
in functionality comes from the 5th patch which is changing the
selection of the clocksource timer for OMAP3 and AM335x devices
when gptimers are used for clocksource. This change came about from
Vaibhav Bedia's series for AM335x [1]. See patch for more details on
the exact nature of the change.

Boot tested with and without  device-tree on OMAP2420 H4, OMAP3430 SDP,
OMAP3430 Beagle Board, OMAP4430 SDP and AM335x EVM (AM335x only
supports device-tree boot). Also boot tested boards with kernel boot
parameter clocksource=gp_timer.

This series is based upon ARM-SoC next branch.

V3 changes:
- Post the intended patches this time!
- Use PTR_ERR() to return the error code if clk_get() fails (thanks
  Russell!)

V2 changes:
- Fixed bug in patch that updates clocksource and clockevents timer
  names to use the hwmod timer names (thanks Vaibhav Bedia!)
- Updated patch that removes the hard-coded ID test to return an error
  as soon as clk_set_parent fails instead of waiting for the end of the
  function.
- Fixed bug in patches that simplify system timer clock definitions
  and simplify system timer definitions that was prevent omap4/5
  boards from booting with kernel boot parameter clocksource=gp_timer.
- Updated changelog for patch simplify system timer definitions per
  feedback received from Igor.
- Added new patch to store the timer ID in the omap_dm_timer structure
  to clean-up the code.
- Added new patch to fix a sparse warning seen in ARM-SOC next.

[1] https://patchwork.kernel.org/patch/1921421/

Jon Hunter (7):
  ARM: OMAP2+: Display correct system timer name
  ARM: OMAP2+: Remove hard-coded test on timer ID
  ARM: OMAP2+: Simplify system timer clock definitions
  ARM: OMAP2+: Simplify system timers definitions
  ARM: OMAP3: Update clocksource timer selection
  ARM: OMAP2+: Store ID of system timers in timer structure
  ARM: OMAP4+: Fix sparse warning in system timers

 arch/arm/mach-omap2/board-cm-t3517.c |2 +-
 arch/arm/mach-omap2/board-generic.c  |2 +-
 arch/arm/mach-omap2/common.h |3 +-
 arch/arm/mach-omap2/timer.c  |  121 +-
 4 files changed, 65 insertions(+), 63 deletions(-)

-- 
1.7.10.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 V3 2/7] ARM: OMAP2+: Remove hard-coded test on timer ID

Currently, when configuring the clock-events and clock-source timers
for OMAP2+ devices, we check whether the timer ID is 12 before
attempting to set the parent clock for the timer.

This test was added for OMAP3 general purpose devices (no security
features enabled) that a 12th timer available but unlike the other
timers only has a single functional clock source. Calling
clk_set_parent() for this 12th timer would always return an error
because there is only one choice for a parent clock. Therefore,
this hard-coded timer ID test was added.

To avoid this timer ID test, simply check to see if the timer's current
parent clock is the desired parent clock and only call clk_set_parent()
if this is not the case.

Also if clk_get() fails, then use PTR_ERR() to return the error code.

Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/timer.c |   27 ++-
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 83118fb..c6b3fdd 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -224,6 +224,7 @@ static int __init omap_dm_timer_init_one(struct 
omap_dm_timer *timer,
struct device_node *np;
struct omap_hwmod *oh;
struct resource irq, mem;
+   struct clk *src;
int r = 0;
 
if (of_have_populated_dt()) {
@@ -278,24 +279,24 @@ static int __init omap_dm_timer_init_one(struct 
omap_dm_timer *timer,
/* After the dmtimer is using hwmod these clocks won't be needed */
timer-fclk = clk_get(NULL, omap_hwmod_get_main_clk(oh));
if (IS_ERR(timer-fclk))
-   return -ENODEV;
+   return PTR_ERR(timer-fclk);
+
+   src = clk_get(NULL, fck_source);
+   if (IS_ERR(src))
+   return PTR_ERR(src);
 
-   /* FIXME: Need to remove hard-coded test on timer ID */
-   if (gptimer_id != 12) {
-   struct clk *src;
-
-   src = clk_get(NULL, fck_source);
-   if (IS_ERR(src)) {
-   r = -EINVAL;
-   } else {
-   r = clk_set_parent(timer-fclk, src);
-   if (IS_ERR_VALUE(r))
-   pr_warn(%s: %s cannot set source\n,
-   __func__, oh-name);
+   if (clk_get_parent(timer-fclk) != src) {
+   r = clk_set_parent(timer-fclk, src);
+   if (IS_ERR_VALUE(r)) {
+   pr_warn(%s: %s cannot set source\n, __func__,
+   oh-name);
clk_put(src);
+   return r;
}
}
 
+   clk_put(src);
+
omap_hwmod_setup_one(oh_name);
omap_hwmod_enable(oh);
__omap_dm_timer_init_regs(timer);
-- 
1.7.10.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 V3 3/7] ARM: OMAP2+: Simplify system timer clock definitions

In commit c59b537 (ARM: OMAP2+: Simplify dmtimer clock aliases), new
clock aliases for dmtimers were added to simplify the code. These clock
aliases can also be used when configuring the system timers and allow us
to remove the current definitions, simplifying the code.

Please note that for OMAP4/5 devices (unlike OMAP2/3 devices), there is
no clock alias for timer_sys_ck with NULL as the device name. Therefore
we still need to use the alias sys_clkin_ck for these devices.

Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/timer.c |   37 ++---
 1 file changed, 14 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index c6b3fdd..b4a06c1 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -57,15 +57,6 @@
 #include common.h
 #include powerdomain.h
 
-/* Parent clocks, eventually these will come from the clock framework */
-
-#define OMAP2_MPU_SOURCE   sys_ck
-#define OMAP3_MPU_SOURCE   OMAP2_MPU_SOURCE
-#define OMAP4_MPU_SOURCE   sys_clkin_ck
-#define OMAP2_32K_SOURCE   func_32k_ck
-#define OMAP3_32K_SOURCE   omap_32k_fck
-#define OMAP4_32K_SOURCE   sys_32k_ck
-
 #define REALTIME_COUNTER_BASE  0x48243200
 #define INCREMENTER_NUMERATOR_OFFSET   0x10
 #define INCREMENTER_DENUMERATOR_RELOAD_OFFSET  0x14
@@ -569,27 +560,27 @@ void __init omap##name##_sync32k_timer_init(void) 
\
 }
 
 #ifdef CONFIG_ARCH_OMAP2
-OMAP_SYS_32K_TIMER_INIT(2, 1, OMAP2_32K_SOURCE, ti,timer-alwon,
-   2, OMAP2_MPU_SOURCE);
+OMAP_SYS_32K_TIMER_INIT(2, 1, timer_32k_ck, ti,timer-alwon,
+   2, timer_sys_ck);
 #endif /* CONFIG_ARCH_OMAP2 */
 
 #ifdef CONFIG_ARCH_OMAP3
-OMAP_SYS_32K_TIMER_INIT(3, 1, OMAP3_32K_SOURCE, ti,timer-alwon,
-   2, OMAP3_MPU_SOURCE);
-OMAP_SYS_32K_TIMER_INIT(3_secure, 12, OMAP3_32K_SOURCE, ti,timer-secure,
-   2, OMAP3_MPU_SOURCE);
-OMAP_SYS_GP_TIMER_INIT(3_gp, 1, OMAP3_MPU_SOURCE, ti,timer-alwon,
-  2, OMAP3_MPU_SOURCE);
+OMAP_SYS_32K_TIMER_INIT(3, 1, timer_32k_ck, ti,timer-alwon,
+   2, timer_sys_ck);
+OMAP_SYS_32K_TIMER_INIT(3_secure, 12, secure_32k_fck, ti,timer-secure,
+   2, timer_sys_ck);
+OMAP_SYS_GP_TIMER_INIT(3_gp, 1, timer_sys_ck, ti,timer-alwon,
+  2, timer_sys_ck);
 #endif /* CONFIG_ARCH_OMAP3 */
 
 #ifdef CONFIG_SOC_AM33XX
-OMAP_SYS_GP_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, ti,timer-alwon,
-  2, OMAP4_MPU_SOURCE);
+OMAP_SYS_GP_TIMER_INIT(3_am33xx, 1, timer_sys_ck, ti,timer-alwon,
+  2, timer_sys_ck);
 #endif /* CONFIG_SOC_AM33XX */
 
 #ifdef CONFIG_ARCH_OMAP4
-OMAP_SYS_32K_TIMER_INIT(4, 1, OMAP4_32K_SOURCE, ti,timer-alwon,
-   2, OMAP4_MPU_SOURCE);
+OMAP_SYS_32K_TIMER_INIT(4, 1, timer_32k_ck, ti,timer-alwon,
+   2, sys_clkin_ck);
 #ifdef CONFIG_LOCAL_TIMERS
 static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, OMAP44XX_LOCAL_TWD_BASE, 29);
 void __init omap4_local_timer_init(void)
@@ -618,8 +609,8 @@ void __init omap4_local_timer_init(void)
 #endif /* CONFIG_ARCH_OMAP4 */
 
 #ifdef CONFIG_SOC_OMAP5
-OMAP_SYS_32K_TIMER_INIT(5, 1, OMAP4_32K_SOURCE, ti,timer-alwon,
-   2, OMAP4_MPU_SOURCE);
+OMAP_SYS_32K_TIMER_INIT(5, 1, timer_32k_ck, ti,timer-alwon,
+   2, sys_clkin_ck);
 void __init omap5_realtime_timer_init(void)
 {
int err;
-- 
1.7.10.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 V3 4/7] ARM: OMAP2+: Simplify system timers definitions

There is a lot of redundancy in the definitions for the various system
timers for OMAP2+ devices. For example, the omap3_am33xx_gptimer_timer_init()
function is the same as the omap3_gp_gptimer_timer_init() function and the
function omap4_sync32k_timer_init() can be re-used for OMAP5 devices.
Therefore, consolidate the definitions to simplify the code.

Signed-off-by: Jon Hunter jon-hun...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Igor Grinberg grinb...@compulab.co.il
---
 arch/arm/mach-omap2/board-cm-t3517.c |2 +-
 arch/arm/mach-omap2/board-generic.c  |2 +-
 arch/arm/mach-omap2/common.h |3 +--
 arch/arm/mach-omap2/timer.c  |   17 -
 4 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/board-cm-t3517.c 
b/arch/arm/mach-omap2/board-cm-t3517.c
index 6a9529a..7c1ad68 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -297,6 +297,6 @@ MACHINE_START(CM_T3517, Compulab CM-T3517)
.handle_irq = omap3_intc_handle_irq,
.init_machine   = cm_t3517_init,
.init_late  = am35xx_init_late,
-   .init_time  = omap3_gp_gptimer_timer_init,
+   .init_time  = omap3_gptimer_timer_init,
.restart= omap3xxx_restart,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 2590463..dfd9f48 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -138,7 +138,7 @@ DT_MACHINE_START(AM33XX_DT, Generic AM33XX (Flattened 
Device Tree))
.init_irq   = omap_intc_of_init,
.handle_irq = omap3_intc_handle_irq,
.init_machine   = omap_generic_init,
-   .init_time  = omap3_am33xx_gptimer_timer_init,
+   .init_time  = omap3_gptimer_timer_init,
.dt_compat  = am33xx_boards_compat,
 MACHINE_END
 #endif
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index b435027..594ab3b 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -82,8 +82,7 @@ extern void omap2_init_common_infrastructure(void);
 extern void omap2_sync32k_timer_init(void);
 extern void omap3_sync32k_timer_init(void);
 extern void omap3_secure_sync32k_timer_init(void);
-extern void omap3_gp_gptimer_timer_init(void);
-extern void omap3_am33xx_gptimer_timer_init(void);
+extern void omap3_gptimer_timer_init(void);
 extern void omap4_local_timer_init(void);
 extern void omap5_realtime_timer_init(void);
 
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b4a06c1..3ad9a3b 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -569,18 +569,19 @@ OMAP_SYS_32K_TIMER_INIT(3, 1, timer_32k_ck, 
ti,timer-alwon,
2, timer_sys_ck);
 OMAP_SYS_32K_TIMER_INIT(3_secure, 12, secure_32k_fck, ti,timer-secure,
2, timer_sys_ck);
-OMAP_SYS_GP_TIMER_INIT(3_gp, 1, timer_sys_ck, ti,timer-alwon,
-  2, timer_sys_ck);
 #endif /* CONFIG_ARCH_OMAP3 */
 
-#ifdef CONFIG_SOC_AM33XX
-OMAP_SYS_GP_TIMER_INIT(3_am33xx, 1, timer_sys_ck, ti,timer-alwon,
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
+OMAP_SYS_GP_TIMER_INIT(3, 1, timer_sys_ck, ti,timer-alwon,
   2, timer_sys_ck);
-#endif /* CONFIG_SOC_AM33XX */
+#endif
 
-#ifdef CONFIG_ARCH_OMAP4
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
 OMAP_SYS_32K_TIMER_INIT(4, 1, timer_32k_ck, ti,timer-alwon,
2, sys_clkin_ck);
+#endif
+
+#ifdef CONFIG_ARCH_OMAP4
 #ifdef CONFIG_LOCAL_TIMERS
 static DEFINE_TWD_LOCAL_TIMER(twd_local_timer, OMAP44XX_LOCAL_TWD_BASE, 29);
 void __init omap4_local_timer_init(void)
@@ -609,13 +610,11 @@ void __init omap4_local_timer_init(void)
 #endif /* CONFIG_ARCH_OMAP4 */
 
 #ifdef CONFIG_SOC_OMAP5
-OMAP_SYS_32K_TIMER_INIT(5, 1, timer_32k_ck, ti,timer-alwon,
-   2, sys_clkin_ck);
 void __init omap5_realtime_timer_init(void)
 {
int err;
 
-   omap5_sync32k_timer_init();
+   omap4_sync32k_timer_init();
realtime_counter_init();
 
err = arch_timer_of_register();
-- 
1.7.10.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 V3 6/7] ARM: OMAP2+: Store ID of system timers in timer structure

Currently, the timer ID is being passed to the function
omap_dm_timer_init_one(). Instead of passing the ID separately, store it
in the omap_dm_timer structure, that is also passed, and access the ID
from this structure.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/timer.c |   11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index fce495e..d0c698f 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -210,7 +210,6 @@ static u32 __init omap_dm_timer_get_errata(void)
 }
 
 static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
-int gptimer_id,
 const char *fck_source,
 const char *property,
 const char **timer_name,
@@ -241,10 +240,10 @@ static int __init omap_dm_timer_init_one(struct 
omap_dm_timer *timer,
 
of_node_put(np);
} else {
-   if (omap_dm_timer_reserve_systimer(gptimer_id))
+   if (omap_dm_timer_reserve_systimer(timer-id))
return -ENODEV;
 
-   sprintf(name, timer%d, gptimer_id);
+   sprintf(name, timer%d, timer-id);
oh_name = name;
}
 
@@ -317,6 +316,7 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
 {
int res;
 
+   clkev.id = gptimer_id;
clkev.errata = omap_dm_timer_get_errata();
 
/*
@@ -326,7 +326,7 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
 */
__omap_dm_timer_override_errata(clkev, OMAP_TIMER_ERRATA_I103_I767);
 
-   res = omap_dm_timer_init_one(clkev, gptimer_id, fck_source, property,
+   res = omap_dm_timer_init_one(clkev, fck_source, property,
 clockevent_gpt.name, OMAP_TIMER_POSTED);
BUG_ON(res);
 
@@ -446,9 +446,10 @@ static void __init omap2_gptimer_clocksource_init(int 
gptimer_id,
 {
int res;
 
+   clksrc.id = gptimer_id;
clksrc.errata = omap_dm_timer_get_errata();
 
-   res = omap_dm_timer_init_one(clksrc, gptimer_id, fck_source, property,
+   res = omap_dm_timer_init_one(clksrc, fck_source, property,
 clocksource_gpt.name,
 OMAP_TIMER_NONPOSTED);
BUG_ON(res);
-- 
1.7.10.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

Re: [PATCH 2/2] ARM: OMAP2: Fix GPMC memory initialisation

* Jon Hunter jon-hun...@ti.com [130204 11:37]:
 
 On 02/04/2013 01:15 PM, Tony Lindgren wrote:
  * Jon Hunter jon-hun...@ti.com [130204 10:49]:
  On 02/04/2013 11:45 AM, Tony Lindgren wrote:
 
  AFAIK SYSBOOT_n values reflect the boot time values of the actual SYSBOOT
  pins, so using generic pinconf there makes sense. But this of course 
  should
  be checked.
 
  Not sure I am a fan of that idea. It is possible the pins could be
  re-used as GPIOs after reset. Given that the state at reset is latched
  in a register, it is best just to read the register directly.
  
  Yes the physical SYSBOOT pins can be reused as GPIO, but that's are already
  handled by the padconf and GPIO registers. This is a different register
  showing the boot time pin values for some pins. So it makes sense to use
  generic pinconf to make the pin values available to the client drivers
  as needed.
  
  The advantage doing it this way is that we don't need to export any omap
  custom functions to the drivers from the SCM driver. This way we need zero
  platform glue code, and can deal with it directly in the drivers in a
  generic way. And all we need to do is just need to map the SoC specific
  SYSBOOT pin register in the .dts files.
 
 I see what you are saying exporting the state in control_status register
 via the pinconf. That could work.
 
  It may also make sense to export DEVICETYPE this way. At least early omaps
  had the GP vs HS mode configured by pulls on some pins during the boot time.
  So those bits too may reflect actual physical pins during the boot time
  configured by the efuse settings?
 
 I *believe* that was only omap1.

Yeah but maybe the efuses just configure some pulls for selected pins for
later omaps?
 
  Regarding omap_device, we should find a way to keep the dependencies
  between drivers and the bus code down to minimum. So ideally things
  like this would be only done using just the compatible flag. But the
  pdata we cannot remove quite yet.
 
  Agree. However, there are several drivers today (gpio, dmtimer, mmc,
  serial, dss, etc), that make use of a function pointer to
  omap_pm_get_dev_context_loss_count() to determine when the peripheral's
  state has been lost. When booting with DT this function pointer is not
  populated and so with DT we currently have no way to determine this. I
  see this as a blocker to migrating completely to DT. Ideally we would
  find a way for RPM to handle this and remove the function pointer.
  However, right now we still need a generic way to pass this type of
  platform data to drivers.
 
  Yeah pinconf generic won't help us with the legacy boot.
 
  Right. I view all this sort of thing as system-level device information
  that some drivers may need. It does not seem that we have a good way to
  handle that at the moment. Any ideas?
  
  I suggest just passing it in in pdata for now for the legacy boot. Then
  I suggest we make what we can generic with pinconf in the long run.
 
 I don't see why we would want to export a function pointer to
 omap_pm_get_dev_context_loss_count() with pinconf. Have we got our wires
 crossed here?

Yes sorry, too many muxes here. I got this topic mixed up with the sysboot
pin topic :)

We really need to find a Linux generic API to query this. Sounds like it
should be part of runtime PM?

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

[PATCH V3 7/7] ARM: OMAP4+: Fix sparse warning in system timers

Commit 6bb27d7 (ARM: delete struct sys_timer) changed the function
created by the macro OMAP_SYS_32K_TIMER_INIT from static void to void.
For OMAP4+ devices this created the following sparse warning ...

arch/arm/mach-omap2/timer.c:585:1: warning: symbol
'omap4_sync32k_timer_init' was not declared. Should it be static?

The function omap4_sync32k_timer_init() is not referenced outside of the
file timer.c and so make this function static.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/timer.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index d0c698f..9fbecd8 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -587,8 +587,8 @@ OMAP_SYS_GP_TIMER_INIT(3, 2, timer_sys_ck, NULL,
 #endif
 
 #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
-OMAP_SYS_32K_TIMER_INIT(4, 1, timer_32k_ck, ti,timer-alwon,
-   2, sys_clkin_ck, NULL);
+static OMAP_SYS_32K_TIMER_INIT(4, 1, timer_32k_ck, ti,timer-alwon,
+  2, sys_clkin_ck, NULL);
 #endif
 
 #ifdef CONFIG_ARCH_OMAP4
-- 
1.7.10.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 V3 5/7] ARM: OMAP3: Update clocksource timer selection

When booting with device-tree for OMAP3 and AM335x devices and a gptimer
is used as the clocksource (which is always the case for AM335x), a
gptimer located in a power domain that is not always-on is selected.
Ideally we should use a gptimer located in a power domain that is always
on (such as the wake-up domain) so that time can be maintained during a
kernel suspend without keeping on additional power domains unnecessarily.

In order to fix this so that we can select a gptimer located in a power
domain that is always-on, the following changes were made ...
1. Currently, only when selecting a gptimer to use for a clockevent
   timer, do we pass a timer property that can be used to select a
   specific gptimer. Change this so that we can pass a property when
   selecting a gptimer to use for a clocksource timer too.
2. Currently, when selecting either a gptimer to use for a clockevent
   timer or a clocksource timer and no timer property is passed, then
   the first available timer is selected regardless of the properties
   it has. Change this so that if no properties are passed, then a timer
   that does not have additional features (such as always-on, dsp-irq,
   pwm, and secure) is selected.

Please note that using a gptimer for both clocksource and clockevents
can have a system power impact during idle. The reason being is that
OMAP and AMxxx devices typically only have one gptimer in a power domain
that is always-on. Therefore when the kernel is idle both the clocksource
and clockevent timers will be active and this will keep additional power
domains on. During kernel suspend, only the clocksource timer is active
and therefore, it is better to use a gptimer in a power domain that is
always-on for clocksource.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/timer.c |   33 +
 1 file changed, 21 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 3ad9a3b..fce495e 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -160,6 +160,12 @@ static struct device_node * __init 
omap_get_timer_dt(struct of_device_id *match,
if (property  !of_get_property(np, property, NULL))
continue;
 
+   if (!property  (of_get_property(np, ti,timer-alwon, NULL) ||
+ of_get_property(np, ti,timer-dsp, NULL) ||
+ of_get_property(np, ti,timer-pwm, NULL) ||
+ of_get_property(np, ti,timer-secure, NULL)))
+   continue;
+
of_add_property(np, device_disabled);
return np;
}
@@ -435,13 +441,14 @@ static int __init __maybe_unused 
omap2_sync32k_clocksource_init(void)
 }
 
 static void __init omap2_gptimer_clocksource_init(int gptimer_id,
-   const char *fck_source)
+ const char *fck_source,
+ const char *property)
 {
int res;
 
clksrc.errata = omap_dm_timer_get_errata();
 
-   res = omap_dm_timer_init_one(clksrc, gptimer_id, fck_source, NULL,
+   res = omap_dm_timer_init_one(clksrc, gptimer_id, fck_source, property,
 clocksource_gpt.name,
 OMAP_TIMER_NONPOSTED);
BUG_ON(res);
@@ -538,47 +545,49 @@ static inline void __init realtime_counter_init(void)
 #endif
 
 #define OMAP_SYS_GP_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop,  \
-  clksrc_nr, clksrc_src)   \
+  clksrc_nr, clksrc_src, clksrc_prop)  \
 void __init omap##name##_gptimer_timer_init(void)  \
 {  \
omap_dmtimer_init();\
omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
-   omap2_gptimer_clocksource_init((clksrc_nr), clksrc_src);\
+   omap2_gptimer_clocksource_init((clksrc_nr), clksrc_src, \
+   clksrc_prop);   \
 }
 
 #define OMAP_SYS_32K_TIMER_INIT(name, clkev_nr, clkev_src, clkev_prop, \
-   clksrc_nr, clksrc_src)  \
+   clksrc_nr, clksrc_src, clksrc_prop) \
 void __init omap##name##_sync32k_timer_init(void)  \
 {  \
omap_dmtimer_init();\
omap2_gp_clockevent_init((clkev_nr), clkev_src, clkev_prop);\
/* Enable the use of clocksource=gp_timer kernel parameter */ \
if (use_gptimer_clksrc) \
-

Re: [PATCH 2/2] ARM: OMAP2: Fix GPMC memory initialisation


On 02/04/2013 01:47 PM, Tony Lindgren wrote:
 * Jon Hunter jon-hun...@ti.com [130204 11:37]:

 On 02/04/2013 01:15 PM, Tony Lindgren wrote:
 * Jon Hunter jon-hun...@ti.com [130204 10:49]:
 On 02/04/2013 11:45 AM, Tony Lindgren wrote:

 AFAIK SYSBOOT_n values reflect the boot time values of the actual SYSBOOT
 pins, so using generic pinconf there makes sense. But this of course 
 should
 be checked.

 Not sure I am a fan of that idea. It is possible the pins could be
 re-used as GPIOs after reset. Given that the state at reset is latched
 in a register, it is best just to read the register directly.

 Yes the physical SYSBOOT pins can be reused as GPIO, but that's are already
 handled by the padconf and GPIO registers. This is a different register
 showing the boot time pin values for some pins. So it makes sense to use
 generic pinconf to make the pin values available to the client drivers
 as needed.

 The advantage doing it this way is that we don't need to export any omap
 custom functions to the drivers from the SCM driver. This way we need zero
 platform glue code, and can deal with it directly in the drivers in a
 generic way. And all we need to do is just need to map the SoC specific
 SYSBOOT pin register in the .dts files.

 I see what you are saying exporting the state in control_status register
 via the pinconf. That could work.

 It may also make sense to export DEVICETYPE this way. At least early omaps
 had the GP vs HS mode configured by pulls on some pins during the boot time.
 So those bits too may reflect actual physical pins during the boot time
 configured by the efuse settings?

 I *believe* that was only omap1.
 
 Yeah but maybe the efuses just configure some pulls for selected pins for
 later omaps?
  
 Regarding omap_device, we should find a way to keep the dependencies
 between drivers and the bus code down to minimum. So ideally things
 like this would be only done using just the compatible flag. But the
 pdata we cannot remove quite yet.

 Agree. However, there are several drivers today (gpio, dmtimer, mmc,
 serial, dss, etc), that make use of a function pointer to
 omap_pm_get_dev_context_loss_count() to determine when the peripheral's
 state has been lost. When booting with DT this function pointer is not
 populated and so with DT we currently have no way to determine this. I
 see this as a blocker to migrating completely to DT. Ideally we would
 find a way for RPM to handle this and remove the function pointer.
 However, right now we still need a generic way to pass this type of
 platform data to drivers.

 Yeah pinconf generic won't help us with the legacy boot.

 Right. I view all this sort of thing as system-level device information
 that some drivers may need. It does not seem that we have a good way to
 handle that at the moment. Any ideas?

 I suggest just passing it in in pdata for now for the legacy boot. Then
 I suggest we make what we can generic with pinconf in the long run.

 I don't see why we would want to export a function pointer to
 omap_pm_get_dev_context_loss_count() with pinconf. Have we got our wires
 crossed here?
 
 Yes sorry, too many muxes here. I got this topic mixed up with the sysboot
 pin topic :)
 
 We really need to find a Linux generic API to query this. Sounds like it
 should be part of runtime PM?

Ideally, yes. I had discussed with Kevin about adding a new state for
logic state lost and then if this could be passed to the RPM resume
callback then we could use this. May be I need to bring this up with Tero.

Cheers
Jon
--
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: [GIT PULL] ARM: OMAP: Audio support via omap-twl4030 and pwm support

* Tony Lindgren t...@atomide.com [130130 14:09]:
 * Peter Ujfalusi peter.ujfal...@ti.com [130129 00:34]:
  Hi Tony,
  
  On 01/22/2013 11:07 AM, Peter Ujfalusi wrote:
   Hi Tony,
   
   The content of this pull:
   
   update for audio support via omap-twl4030 and pwm updates in board level:
   http://www.spinics.net/lists/linux-omap/msg85085.html
   
   and zoom-peripherals update to not request the TWL GPIO7:
   http://www.spinics.net/lists/linux-omap/msg85187.html
   
   All is on top of mainline v3.8-rc4 tag.
  
  Have you already pulled this one? I can not find the patches in linux-next.
 
 Pulled now thanks. Will push out to omap-for-v3.9/twl.

Looks like this now adds some new section warnings:

WARNING: vmlinux.o(.text+0x34124): Section mismatch in reference from the 
function sdp3430_twl_gpio_setup() to the function 
.init.text:omap_twl4030_audio_init()
The function sdp3430_twl_gpio_setup() references
the function __init omap_twl4030_audio_init().
This is often because sdp3430_twl_gpio_setup lacks a __init 
annotation or the annotation of omap_twl4030_audio_init is wrong.

WARNING: vmlinux.o(.text+0x34b8c): Section mismatch in reference from the 
function zoom_twl_gpio_setup() to the function 
.init.text:omap_twl4030_audio_init()
The function zoom_twl_gpio_setup() references
the function __init omap_twl4030_audio_init().
This is often because zoom_twl_gpio_setup lacks a __init 
annotation or the annotation of omap_twl4030_audio_init is wrong.

These can be fixed with the following patch, but I suspect some
of these cannot be __init/__initdata if the driver reprobes.

Can you please check this? I'll hold on sendinf off
this branch until it's been checked and fixed properly.

Regards,

Tony


--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -223,7 +223,7 @@ static struct omap_tw4030_pdata omap_twl4030_audio_data = {
.has_linein = OMAP_TWL4030_LEFT | OMAP_TWL4030_RIGHT,
 };
 
-static int sdp3430_twl_gpio_setup(struct device *dev,
+static int __init sdp3430_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
 {
/* gpio + 0 is mmc0_cd (input/IRQ),
@@ -245,7 +245,7 @@ static int sdp3430_twl_gpio_setup(struct device *dev,
return 0;
 }
 
-static struct twl4030_gpio_platform_data sdp3430_gpio_data = {
+static struct twl4030_gpio_platform_data __initdata sdp3430_gpio_data = {
.pulldowns  = BIT(2) | BIT(6) | BIT(8) | BIT(13)
| BIT(16) | BIT(17),
.setup  = sdp3430_twl_gpio_setup,
@@ -374,7 +374,7 @@ static struct regulator_init_data sdp3430_vsim = {
.consumer_supplies  = sdp3430_vsim_supplies,
 };
 
-static struct twl4030_platform_data sdp3430_twldata = {
+static struct twl4030_platform_data __initdata sdp3430_twldata = {
/* platform_data for children goes here */
.gpio   = sdp3430_gpio_data,
.keypad = sdp3430_kp_data,
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -238,7 +238,7 @@ static struct omap_tw4030_pdata omap_twl4030_audio_data = {
.has_linein = OMAP_TWL4030_LEFT | OMAP_TWL4030_RIGHT,
 };
 
-static int zoom_twl_gpio_setup(struct device *dev,
+static int __init zoom_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
 {
/* gpio + 0 is mmc0_cd (input/IRQ) */
@@ -252,11 +252,11 @@ static int zoom_twl_gpio_setup(struct device *dev,
return 0;
 }
 
-static struct twl4030_gpio_platform_data zoom_gpio_data = {
+static struct twl4030_gpio_platform_data __initdata zoom_gpio_data = {
.setup  = zoom_twl_gpio_setup,
 };
 
-static struct twl4030_platform_data zoom_twldata = {
+static struct twl4030_platform_data __initdata zoom_twldata = {
/* platform_data for children goes here */
.gpio   = zoom_gpio_data,
.keypad = zoom_kp_twl4030_data,
--
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 29/32] usb: gadget: pxa27x_udc: let udc-core manage gadget-dev

On Mon, Jan 28, 2013 at 09:18:29PM +0100, Robert Jarzmik wrote:
 Felipe Balbi ba...@ti.com writes:
 
  By simply setting a flag, we can drop some
  boilerplate code.
 
  Signed-off-by: Felipe Balbi ba...@ti.com
  ---
   drivers/usb/gadget/pxa27x_udc.c | 9 +
 Acked-by: Robert Jarzmik robert.jarz...@free.fr
 
 And I tested also your patch and it works in my environment. For next patches
 I'd like to be CCed for pxa27x_udc stuff as I'm maintaining that one since its
 beginning (and yes, I know, I didn't put that in MAINTAINERS ...).

you should add yourself to MAINTAINERS. Please send a patch to Greg when
you have time.

No need to prepare a tree, though. I just need you to give your Acked-by
and I'll queue the patches myself.

cheers

-- 
balbi


signature.asc
Description: Digital signature

[GIT PULL 1/4] omap non-critical fixes for v3.9 merge window

The following changes since commit 88b62b915b0b7e25870eb0604ed9a92ba4bfc9f7:

  Linux 3.8-rc6 (2013-02-01 12:08:14 +1100)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v3.9/fixes-non-critical-signed-v2

for you to fetch changes up to c8d4bafe503ca767bbc8f3c54e4acd344ef26346:

  ARM: OMAP2+: using strlcpy instead of strncpy (2013-02-04 10:17:37 -0800)


Few fixes for v3.9 merge window that are not urgent for
the -rc series.


Chen Gang (2):
  ARM: OMAP: Fix the use of uninitialized dma_lch_count
  ARM: OMAP2+: using strlcpy instead of strncpy

Jon Hunter (1):
  ARM: OMAP2+: Fix selection of clockevent timer when using device-tree

Thomas Gleixner (1):
  ARM: OMAP: make wakeupgen_lock raw

 arch/arm/mach-omap2/omap-wakeupgen.c | 14 +++---
 arch/arm/mach-omap2/timer.c  |  2 +-
 arch/arm/mach-omap2/twl-common.c |  3 ++-
 arch/arm/plat-omap/dma.c |  2 +-
 4 files changed, 11 insertions(+), 10 deletions(-)
--
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 01/10] ARM: davinci: move private EDMA API to arm/common

2013-02-04 Thread Linus Walleij

On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy cy...@ti.com wrote:

I cannot understand the actual technical problem from the above
paragraphs though. dmaengine doesn't have a concept of pushing
nor polling, it basically copies streams of words from A to B, where
A/B can be a device or a buffer, nothing else.

The thing you're looking for sounds more like an adapter on top
of dmaengine, which can surely be constructed, some
drivers/dma/dmaengine-napi.c or whatever.

The second problem is one of binding fixed DMA resources to fixed users.
AFAICT, the stock DMA-Engine mechanism works best when one DMA
resource is as good as any other.

The filter function picks a channel for whatever reason. That reason
can be, well whatever. Some engines have a clever mechanism to
select resources on the other end.

Then for tying devices to channels we have the dmaengine
DT branch:
http://git.infradead.org/users/vkoul/slave-dma.git/shortlog/refs/heads/topic/dmaengine_dt

This stuff didn't go into v3.8 but you can *sure* expect it
to be in v3.9.

Or are you referring to a multi-engine scenario? Say if there is engine
A and B and depending on circumstances A or B may be preferred
in some order (and permutations of this problem). That is currently
identified as a shortcoming that we need help to address.

To get over this problem, we've added
support for named channels, and drivers specifically request for a DMA
resource by name. Again, this is less than ideal.

Jon Hunter has been working on a mechanism to look up DMA channels
from struct device *, dev_name() or a device tree node for example.
Just like we do with clocks or regulators.

Look at this patch from the dmaengine_dt branch:
http://git.infradead.org/users/vkoul/slave-dma.git/commitdiff/528499a7037ebec0636d928f88cd783c618df3c5

Looks up an optionally named channel for a certain
device.

It currently only supports device tree, but you are free to
patch in whatever mechanism you need there. Static tables
in platform data works too. Just nobody did it.

So go ahead and hack on dma_request_slave_channel().
(I would just branch of the DT branch.)

Not that I understand the polling issue, but it sounds to me like
what Jon is doing is similar.

Surely the way to look up resources cannot be paramount in this
discussion, I think the real problem must be your specific networking
usecase, so we need to drill into that.

Yours,
Linus Walleij
--
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 01/10] ARM: davinci: move private EDMA API to arm/common

2013-02-04 Thread Mark Brown

On Mon, Feb 04, 2013 at 09:29:46PM +0100, Linus Walleij wrote:
 On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy cy...@ti.com wrote:

  Based on our experience with fitting multiple subsystems on top of this
  DMA-Engine driver, I must say that the DMA-Engine interface has proven
  to be a less than ideal fit for the network driver use case.

  The first problem is that the DMA-Engine interface expects to push
  completed traffic up into the upper layer as a part of its callback.
  This doesn't fit cleanly with NAPI, which expects to pull completed
  traffic from below in the NAPI poll.  We've somehow kludged together a
  solution around this, but it isn't very elegant.

 I cannot understand the actual technical problem from the above
 paragraphs though. dmaengine doesn't have a concept of pushing
 nor polling, it basically copies streams of words from A to B, where
 A/B can be a device or a buffer, nothing else.

 The thing you're looking for sounds more like an adapter on top
 of dmaengine, which can surely be constructed, some
 drivers/dma/dmaengine-napi.c or whatever.

Broadly speaking what NAPI wants is to never get any callbacks from the
hardware (or DMAs).  It wants to wake up periodically, take a look at
what packets have been read by the hardware and process them.  The goal
is to have the DMAs sitting and running without disturbing the processor
at all after the first packet has been handled.


signature.asc
Description: Digital signature

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

2013-02-04 Thread Linus Walleij

On Mon, Feb 4, 2013 at 9:33 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
 On Mon, Feb 04, 2013 at 09:29:46PM +0100, Linus Walleij wrote:
 On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy cy...@ti.com wrote:

  Based on our experience with fitting multiple subsystems on top of this
  DMA-Engine driver, I must say that the DMA-Engine interface has proven
  to be a less than ideal fit for the network driver use case.

  The first problem is that the DMA-Engine interface expects to push
  completed traffic up into the upper layer as a part of its callback.
  This doesn't fit cleanly with NAPI, which expects to pull completed
  traffic from below in the NAPI poll.  We've somehow kludged together a
  solution around this, but it isn't very elegant.

 I cannot understand the actual technical problem from the above
 paragraphs though. dmaengine doesn't have a concept of pushing
 nor polling, it basically copies streams of words from A to B, where
 A/B can be a device or a buffer, nothing else.

 The thing you're looking for sounds more like an adapter on top
 of dmaengine, which can surely be constructed, some
 drivers/dma/dmaengine-napi.c or whatever.

 Broadly speaking what NAPI wants is to never get any callbacks from the
 hardware (or DMAs).  It wants to wake up periodically, take a look at
 what packets have been read by the hardware and process them.  The goal
 is to have the DMAs sitting and running without disturbing the processor
 at all after the first packet has been handled.

OK we should definately be able to encompass that in dmaengine
quite easily.

So I think the above concerns are moot. The callback we can
set on cookies is entirely optional, and it's even implemented by
each DMA engine, and some may not even support it but *require*
polling, and then it won't even be implemented by the driver.

Which probably stems from the original design of the dmaengine
API, which was for TCP networking acceleration, mainly.

Cyril, just stack up the cookies and take a sweep over them to see
which ones are baked when the NAPI poll comes in - problem
solved.

Yours,
Linus Walleij
--
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 05/13] USB: ehci-omap: Get platform resources by index rather than by name

On Mon, 4 Feb 2013, Roger Quadros wrote:

 Since there is only one resource per type we don't really need
 to use resource name to obtain it. This also also makes it easier
 for device tree adaptation.
 
 Signed-off-by: Roger Quadros rog...@ti.com

Acked-by: Alan Stern st...@rowland.harvard.edu

--
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 06/13] USB: ohci-omap3: Get platform resources by index rather than by name

On Mon, 4 Feb 2013, Roger Quadros wrote:

 Since there is only one resource per type we don't really need
 to use resource name to obtain it. This also also makes it easier
 for device tree adaptation.
 
 Signed-off-by: Roger Quadros rog...@ti.com

Acked-by: Alan Stern st...@rowland.harvard.edu


--
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 07/13] USB: ohci-omap3: Add device tree support and binding information

On Mon, 4 Feb 2013, Roger Quadros wrote:

 Allows the OHCI controller found in OMAP3 and later chips to
 be specified via device tree.
 
 Signed-off-by: Roger Quadros rog...@ti.com

For the ohci-omap3 part:

Acked-by: Alan Stern st...@rowland.harvard.edu


--
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 08/13] USB: ehci-omap: Add device tree support and binding information

On Mon, 4 Feb 2013, Roger Quadros wrote:

 Allows the OMAP EHCI controller to be specified via device tree.
 
 Signed-off-by: Roger Quadros rog...@ti.com

For the ehci-omap part:

Acked-by: Alan Stern st...@rowland.harvard.edu


--
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 01/10] ARM: davinci: move private EDMA API to arm/common

2013-02-04 Thread Arnd Bergmann

On Monday 04 February 2013, Linus Walleij wrote:
 So I think the above concerns are moot. The callback we can
 set on cookies is entirely optional, and it's even implemented by
 each DMA engine, and some may not even support it but require
 polling, and then it won't even be implemented by the driver.

Just to ensure that everybody is talking about the same thing here:
Is it just the callback that is optional, or also the interrupt
coming from the hardware? With NAPI, you want to avoid both, since
getting an interrupt for every packet adds noticeable overhead,
but you still want to be able to tell the hardware that you
are fed up with polling and would like to get an interrupt again
when the next data arrives (ideally, after either a little time
has passed after the next packet, or a specific number of packets
has arrived).

Arnd
--
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 01/10] ARM: davinci: move private EDMA API to arm/common

2013-02-04 Thread Cyril Chemparathy


On 02/04/2013 04:11 PM, Linus Walleij wrote:

On Mon, Feb 4, 2013 at 9:33 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:

On Mon, Feb 04, 2013 at 09:29:46PM +0100, Linus Walleij wrote:

On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy cy...@ti.com wrote:



Based on our experience with fitting multiple subsystems on top of this
DMA-Engine driver, I must say that the DMA-Engine interface has proven
to be a less than ideal fit for the network driver use case.



The first problem is that the DMA-Engine interface expects to push
completed traffic up into the upper layer as a part of its callback.
This doesn't fit cleanly with NAPI, which expects to pull completed
traffic from below in the NAPI poll.  We've somehow kludged together a
solution around this, but it isn't very elegant.



I cannot understand the actual technical problem from the above
paragraphs though. dmaengine doesn't have a concept of pushing
nor polling, it basically copies streams of words from A to B, where
A/B can be a device or a buffer, nothing else.



The thing you're looking for sounds more like an adapter on top
of dmaengine, which can surely be constructed, some
drivers/dma/dmaengine-napi.c or whatever.


Broadly speaking what NAPI wants is to never get any callbacks from the
hardware (or DMAs).  It wants to wake up periodically, take a look at
what packets have been read by the hardware and process them.  The goal
is to have the DMAs sitting and running without disturbing the processor
at all after the first packet has been handled.


OK we should definately be able to encompass that in dmaengine
quite easily.

So I think the above concerns are moot. The callback we can
set on cookies is entirely optional, and it's even implemented by
each DMA engine, and some may not even support it but *require*
polling, and then it won't even be implemented by the driver.

Which probably stems from the original design of the dmaengine
API, which was for TCP networking acceleration, mainly.

Cyril, just stack up the cookies and take a sweep over them to see
which ones are baked when the NAPI poll comes in - problem
solved.



You're assuming that cookies complete in order.  That is not necessarily 
true.


Thanks
-- Cyril.
--
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/2] ARM: OMAP2: Fix GPMC memory initialisation


On 02/01/2013 03:51 PM, Tony Lindgren wrote:

 How about let's fix this properly to start with so we don't add
 more blockers moving this code to drivers/bus?
 
 Looks like gpmc_mem_init() gets called from gpmc_probe() so
 we can pass that information in pdev.

I have re-worked this a bit to use platform data. I have also updated
the logic for testing internal/external boot on omap2430 which is
different from omap2420 (according to the TRM). However, I have only
boot tested on omap2420. 

Do you know why this was changed in the first place? See below ...

http://permalink.gmane.org/gmane.linux.kernel.commits.head/95931

Heres what I have now ...


From df2eebd3580f478f569241d294c2f810359fab6a Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Thu, 31 Jan 2013 15:56:08 -0600
Subject: [PATCH] ARM: OMAP2: Fix GPMC memory initialisation

OMAP2+ devices have an internal ROM that by default is typically mapped
to the first 1MB of the GPMC address space (0x0).

For OMAP24xx devices, GPMC chip-select 0 (CS0) may be mapped to address
0x0 instead of the internal ROM if configured for an external boot mode.
If configured for an internal boot mode then the internal ROM is mapped
to 0x0.

Currently, the function gpmc_mem_init() function reserves the first 1MB
of GPMC address space for the internal OMAP ROM. This prevents any
device (ethernet chip, flash memories, etc) from using this address
range. This causes the GPMC probe to fail on the OMAP2420 H4 when NOR
flash is mapped to address 0x0. Fix this by checking the SYS_BOOT pin
setting for OMAP24xx devices, to see the device is configured for
an internal or external boot and pass the amount of ROM mapped to
address 0x0 to the GPMC driver via platform data.

Please note that for OMAP3-5 devices, when booting from NOR or NAND
memories connected to CS0, these memories are always mapped to address
0x0800 and so reserving this memory range does not present any
problems for these devices.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/gpmc.c |   53 +++-
 arch/arm/mach-omap2/gpmc.h |5 +
 2 files changed, 48 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index a124849..71c0134 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -20,6 +20,7 @@
 #include linux/err.h
 #include linux/clk.h
 #include linux/ioport.h
+#include linux/slab.h
 #include linux/spinlock.h
 #include linux/io.h
 #include linux/module.h
@@ -32,6 +33,7 @@
 
 #include soc.h
 #include common.h
+#include control.h
 #include omap_device.h
 #include gpmc.h
 
@@ -87,7 +89,6 @@
 
 #define GPMC_MEM_START 0x
 #define GPMC_MEM_END   0x3FFF
-#define BOOT_ROM_SPACE 0x10/* 1MB */
 
 #define GPMC_CHUNK_SHIFT   24  /* 16 MB */
 #define GPMC_SECTION_SHIFT 28  /* 128 MB */
@@ -775,16 +776,11 @@ static void gpmc_mem_exit(void)
 
 }
 
-static int gpmc_mem_init(void)
+static int gpmc_mem_init(u32 offset)
 {
int cs, rc;
-   unsigned long boot_rom_space = 0;
 
-   /* never allocate the first page, to facilitate bug detection;
-* even if we didn't boot from ROM.
-*/
-   boot_rom_space = BOOT_ROM_SPACE;
-   gpmc_mem_root.start = GPMC_MEM_START + boot_rom_space;
+   gpmc_mem_root.start = GPMC_MEM_START + offset;
gpmc_mem_root.end = GPMC_MEM_END;
 
/* Reserve all regions that has been set up by bootloader */
@@ -1124,6 +1120,12 @@ static int gpmc_probe(struct platform_device *pdev)
int rc;
u32 l;
struct resource *res;
+   struct gpmc_platform_data *pdata = pdev-dev.platform_data;
+
+   if (!pdata) {
+   dev_err(pdev-dev, %s: no platform data.\n, __func__);
+   return -ENODEV;
+   }
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL)
@@ -1161,7 +1163,7 @@ static int gpmc_probe(struct platform_device *pdev)
dev_info(gpmc_dev, GPMC revision %d.%d\n, GPMC_REVISION_MAJOR(l),
 GPMC_REVISION_MINOR(l));
 
-   rc = gpmc_mem_init();
+   rc = gpmc_mem_init(pdata-gpmc_rom_space);
if (IS_ERR_VALUE(rc)) {
clk_disable_unprepare(gpmc_l3_clk);
clk_put(gpmc_l3_clk);
@@ -1213,15 +1215,46 @@ static int __init omap_gpmc_init(void)
 {
struct omap_hwmod *oh;
struct platform_device *pdev;
+   struct gpmc_platform_data *pdata;
char *oh_name = gpmc;
 
+   pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   pr_err(%s: No memory for gpmc\n, __func__);
+   return -ENOMEM;
+   }
+
+   /*
+* The first 1MB of GPMC address space is mapped to the internal
+* ROM. OMAP2 devices are an exception to this where the first
+* 1MB may be mapped to the GPMC. OMAP2 devices that boot from
+*

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

2013-02-04 Thread Cyril Chemparathy


On 02/04/2013 03:29 PM, Linus Walleij wrote:

On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy cy...@ti.com wrote:


Based on our experience with fitting multiple subsystems on top of this
DMA-Engine driver, I must say that the DMA-Engine interface has proven
to be a less than ideal fit for the network driver use case.

The first problem is that the DMA-Engine interface expects to push
completed traffic up into the upper layer as a part of its callback.
This doesn't fit cleanly with NAPI, which expects to pull completed
traffic from below in the NAPI poll.  We've somehow kludged together a
solution around this, but it isn't very elegant.


I cannot understand the actual technical problem from the above
paragraphs though. dmaengine doesn't have a concept of pushing
nor polling, it basically copies streams of words from A to B, where
A/B can be a device or a buffer, nothing else.



NAPI needs to switch between polled and interrupt driven modes of 
operation.  Further, in a given poll, it needs to be able to limit the 
amount of traffic processed to a specified budget.



The thing you're looking for sounds more like an adapter on top
of dmaengine, which can surely be constructed, some
drivers/dma/dmaengine-napi.c or whatever.



I'm not debating the possibility of duct-taping a network driver on top 
of the dma-engine interface.  That is very much doable, and we have done 
this already.


Starting with a stock dma-engine driver, our first approach was to use 
dmaengine_pause() and dmaengine_resume() in the network driver to 
throttle completion callbacks per NAPI's needs.  This worked, but it was 
ugly because the completion callback was now being used in a 
multi-purpose fashion - (a) as an interrupt notifier [to do a 
napi_schedule()], and (b) as a hand over mechanism for completed packets 
[within a napi_poll()].  The network driver needed to maintain a nasty 
little state machine for this, and this ended up being quite non-trivial 
after we'd fixed up most of the issues.


Having learned our lessons from the first attempt, the second step was 
to add a separate notification callback from the dma-engine layer - a 
notification independent of any particular descriptor.  With this 
callback in place, we got rid of some of the state machine crap in the 
network driver.


The third step was to add a dmaengine_poll() call instead of constantly 
bouncing a channel between paused and running states.  This further 
cleaned up some of the network driver code, but now the dma-engine 
driver looks like crap if it needs to support both the traditional and 
new (i.e. notify + poll) modes.  This is where we are at today.


Even with the addition of these extensions, the interaction between the 
network driver and the dma-engine driver is clumsy and involves multiple 
back and forth calls per packet.  This is not elegant, and certainly not 
efficient.  In comparison, the virtqueue interface is a natural fit with 
the network driver, and is free of the aforementioned problems.


[...]

Surely the way to look up resources cannot be paramount in this
discussion, I think the real problem must be your specific networking
usecase, so we need to drill into that.



Agreed.  The dma resource to driver binding is certainly a lesser 
problem than the first.  There are a variety of schemes that we could 
cook up here (filter functions, named lookups, etc.).  However, I think 
that these schemes offer advantages when the binding between the dma 
resource and the dma user is somewhat dynamic.


On the other hand, when the binding between a dma resource and user is 
fixed by hardware and/or configuration, the driver model approach works 
better, IMHO.


Thanks
-- Cyril.
--
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/2] ARM: OMAP2: Fix GPMC memory initialisation


On 02/04/2013 04:12 PM, Jon Hunter wrote:
 
 On 02/01/2013 03:51 PM, Tony Lindgren wrote:
 
 How about let's fix this properly to start with so we don't add
 more blockers moving this code to drivers/bus?

 Looks like gpmc_mem_init() gets called from gpmc_probe() so
 we can pass that information in pdev.
 
 I have re-worked this a bit to use platform data. I have also update
 the logic for testing internal/external boot on omap2430 which is
 different from omap2420 (according to the TRM). However, I have only
 boot tested on omap2420. 
 
 Do you know why this was changed in the first place? See below ...
 
 http://permalink.gmane.org/gmane.linux.kernel.commits.head/95931
 
 Heres what I have now ...

Updated patch (I was missing a kfree()). By the way, this is based
upon the apollon removal patch. I understand probably needs to be
rebased on your latest gpmc series too.

Jon

From 643656e3754ed949d9a8af31b22ed3727e0962f6 Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Thu, 31 Jan 2013 15:56:08 -0600
Subject: [PATCH] ARM: OMAP2: Fix GPMC memory initialisation

OMAP2+ devices have an internal ROM that by default is typically mapped
to the first 1MB of the GPMC address space (0x0).

For OMAP24xx devices, GPMC chip-select 0 (CS0) may be mapped to address
0x0 instead of the internal ROM if configured for an external boot mode.
If configured for an internal boot mode then the internal ROM is mapped
to 0x0.

Currently, the function gpmc_mem_init() function reserves the first 1MB
of GPMC address space for the internal OMAP ROM. This prevents any
device (ethernet chip, flash memories, etc) from using this address
range. This causes the GPMC probe to fail on the OMAP2420 H4 when NOR
flash is mapped to address 0x0. Fix this by checking the SYS_BOOT pin
setting for OMAP24xx devices, to see the device is configured for
an internal or external boot and pass the amount of ROM mapped to
address 0x0 to the GPMC driver via platform data.

Please note that for OMAP3-5 devices, when booting from NOR or NAND
memories connected to CS0, these memories are always mapped to address
0x0800 and so reserving this memory range does not present any
problems for these devices.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/gpmc.c |   60 
 arch/arm/mach-omap2/gpmc.h |5 
 2 files changed, 54 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index a124849..aa58258 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -20,6 +20,7 @@
 #include linux/err.h
 #include linux/clk.h
 #include linux/ioport.h
+#include linux/slab.h
 #include linux/spinlock.h
 #include linux/io.h
 #include linux/module.h
@@ -32,6 +33,7 @@
 
 #include soc.h
 #include common.h
+#include control.h
 #include omap_device.h
 #include gpmc.h
 
@@ -87,7 +89,6 @@
 
 #define GPMC_MEM_START 0x
 #define GPMC_MEM_END   0x3FFF
-#define BOOT_ROM_SPACE 0x10/* 1MB */
 
 #define GPMC_CHUNK_SHIFT   24  /* 16 MB */
 #define GPMC_SECTION_SHIFT 28  /* 128 MB */
@@ -775,16 +776,11 @@ static void gpmc_mem_exit(void)
 
 }
 
-static int gpmc_mem_init(void)
+static int gpmc_mem_init(u32 offset)
 {
int cs, rc;
-   unsigned long boot_rom_space = 0;
 
-   /* never allocate the first page, to facilitate bug detection;
-* even if we didn't boot from ROM.
-*/
-   boot_rom_space = BOOT_ROM_SPACE;
-   gpmc_mem_root.start = GPMC_MEM_START + boot_rom_space;
+   gpmc_mem_root.start = GPMC_MEM_START + offset;
gpmc_mem_root.end = GPMC_MEM_END;
 
/* Reserve all regions that has been set up by bootloader */
@@ -1124,6 +1120,12 @@ static int gpmc_probe(struct platform_device *pdev)
int rc;
u32 l;
struct resource *res;
+   struct gpmc_platform_data *pdata = pdev-dev.platform_data;
+
+   if (!pdata) {
+   dev_err(pdev-dev, %s: no platform data.\n, __func__);
+   return -ENODEV;
+   }
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL)
@@ -1161,7 +1163,7 @@ static int gpmc_probe(struct platform_device *pdev)
dev_info(gpmc_dev, GPMC revision %d.%d\n, GPMC_REVISION_MAJOR(l),
 GPMC_REVISION_MINOR(l));
 
-   rc = gpmc_mem_init();
+   rc = gpmc_mem_init(pdata-gpmc_rom_space);
if (IS_ERR_VALUE(rc)) {
clk_disable_unprepare(gpmc_l3_clk);
clk_put(gpmc_l3_clk);
@@ -1213,18 +1215,54 @@ static int __init omap_gpmc_init(void)
 {
struct omap_hwmod *oh;
struct platform_device *pdev;
+   struct gpmc_platform_data *pdata;
char *oh_name = gpmc;
 
+   pdata = kzalloc(sizeof(struct gpmc_platform_data), GFP_KERNEL);
+   if (!pdata) {
+   pr_err(%s: No memory for gpmc\n, __func__);
+   return -ENOMEM;
+

Re: [PATCH] ARM:omap2: using strlcpy instead of strncpy

2013-02-04 Thread Chen Gang

于 2013年02月05日 02:18, Tony Lindgren 写道:
 * Peter Ujfalusi peter.ujfal...@ti.com [130204 01:04]:
  Hi Tony,
  
  I can create a branch for you in our gitorious tree
  (git://gitorious.org/omap-audio/linux-audio.git) for this patch. But I 
  think
  for now it would be best if you could take this via linux-omap (the file is
  under arch/arm/mach-omap2 anyways)
 OK thanks I'll apply with your ack to omap-for-v3.9/fixes-noncritical.
 
 Tony
 

  Does it mean: we need not sync MAINTAINERS file for twl-*, recently ?

  :-)

  thanks.
-- 
Chen Gang

Asianux Corporation
--
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 02/13] USB: phy: nop: Defer probe if device needs VCC/RESET


On Monday 04 February 2013 09:28 PM, Roger Quadros wrote:

Add 2 flags, needs_vcc and needs_reset to platform data.
If the flag is set and the regulator couldn't be found
then we bail out with -EPROBE_DEFER.

For device tree boot we depend on presensce of vcc-supply/
reset-supply properties to decide if we should bail out
with -EPROBE_DEFER or just continue in case the regulator
can't be found.

This is required for proper functionality in cases where the
regulator is needed but is probed later than the PHY device.

Signed-off-by: Roger Quadros rog...@ti.com
---
  drivers/usb/otg/nop-usb-xceiv.c   |8 
  include/linux/usb/nop-usb-xceiv.h |4 
  2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index adbb7ab..7860e7569 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -147,6 +147,10 @@ static void nop_xeiv_get_dt_pdata(struct device *dev,

if (!of_property_read_u32(node, clock-frequency, clk_rate))
pdata-clk_rate = clk_rate;
+   if (of_property_read_bool(node, vcc-supply))
+   pdata-needs_vcc = true;

This can be written as..
pdata-needs_vcc = of_property_read_bool(node, vcc-supply);


+   if (of_property_read_bool(node, reset-supply))
+   pdata-needs_reset = true;

same here..

  }

  static int nop_usb_xceiv_probe(struct platform_device *pdev)
@@ -205,12 +209,16 @@ static int nop_usb_xceiv_probe(struct platform_device 
*pdev)
if (IS_ERR(nop-vcc)) {
dev_dbg(pdev-dev, Error getting vcc regulator: %ld\n,
PTR_ERR(nop-vcc));
+   if (pdata-needs_vcc)
+   return -EPROBE_DEFER;
}

nop-reset = devm_regulator_get(pdev-dev, reset);
if (IS_ERR(nop-reset)) {
dev_dbg(pdev-dev, Error getting reset regulator: %ld\n,
PTR_ERR(nop-reset));
+   if (pdata-needs_reset)
+   return -EPROBE_DEFER;
}

nop-dev = pdev-dev;
diff --git a/include/linux/usb/nop-usb-xceiv.h 
b/include/linux/usb/nop-usb-xceiv.h
index 3265b61..148d351 100644
--- a/include/linux/usb/nop-usb-xceiv.h
+++ b/include/linux/usb/nop-usb-xceiv.h
@@ -6,6 +6,10 @@
  struct nop_usb_xceiv_platform_data {
enum usb_phy_type type;
unsigned long clk_rate;
+
+   /* if set fails with -EPROBE_DEFER if can't get regulator */
+   unsigned int needs_vcc:1;
+   unsigned int needs_reset:1;


how about u8 here?

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 04/13] mfd: omap-usb-tll: Add device tree support


On Monday 04 February 2013 09:28 PM, Roger Quadros wrote:

Enable this driver to probe in device tree boot.

CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
  .../devicetree/bindings/mfd/omap-usb-tll.txt   |   17 +
  drivers/mfd/omap-usb-tll.c |9 +
  2 files changed, 26 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-tll.txt

diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt 
b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
new file mode 100644
index 000..835cf4f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
@@ -0,0 +1,17 @@
+OMAP HS USB Host TLL (Transceiver-Less Interface)
+
+Required properties:
+
+- compatible : should be ti,usbhs-tll
+- reg : should contain one register range i.e. start and length
+- interrupts : should contain the TLL module's interrupt
+- ti,hwmod : must contain usb_tll_hs
+
+Example:
+
+   usbhstll: usbhstll@0x4a062000 {
The node name shouldn't have 0x. This comment applies to all your 
patches adding device tree support.


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 09/13] mfd: omap-usb-host: Add device tree support and binding information


On Monday 04 February 2013 09:28 PM, Roger Quadros wrote:

Allows the OMAP HS USB host controller to be specified
via device tree.

CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
  .../devicetree/bindings/mfd/omap-usb-host.txt  |   68 
  drivers/mfd/omap-usb-host.c|   83 ++--
  2 files changed, 145 insertions(+), 6 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-host.txt

diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt 
b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
new file mode 100644
index 000..2196893
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
@@ -0,0 +1,68 @@
+OMAP HS USB Host
+
+Required properties:
+
+- compatible: should be ti,usbhs-host
+- reg: should contain one register range i.e. start and length
+- ti,hwmods: must contain usb_host_hs
+
+Optional properties:
+
+- nports: number of USB ports. Usually this is automatically detected
+  from the IP's revision register but can be overridden by specifying
+  this property.
+
+- portN_mode: Integer specifying the port mode for port N, where N can be
+  from 1 to nports. The port mode must be as per enum usbhs_omap_port_mode
+  in include/linux/platform_data/usb-omap.h
+  If the port mode is not specified, that port is treated as unused.
+
+- single_ulpi_bypass: Must be present if the controller contains a single
+  ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1
+
+Required properties if child node exists:
+
+- #address-cells: Must be 1
+- #size-cells: Must be 1
+- ranges: must be present
+
+Properties for children:
+
+The OMAP HS USB Host subsystem contains EHCI and OHCI controllers.
+See Documentation/devicetree/bindings/usb/omap-ehci.txt and
+omap3-ohci.txt
+
+Example for OMAP4:
+
+usbhshost: usbhshost@0x4a064000 {
+   compatible = ti,usbhs-host;
+   reg = 0x4a064000 0x800;
+   ti,hwmods = usb_host_hs;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+
+   usbhsohci: ohci@0x4a064800 {
+   compatible = ti,omap3-ohci, usb-ohci;
+   reg = 0x4a064800 0x400;
+   interrupt-parent = gic;
+   interrupts = 0 76 0x4;
+   };
+
+   usbhsehci: ehci@0x4a064c00 {
+   compatible = ti,omap-ehci, usb-ehci;
+   reg = 0x4a064c00 0x400;
+   interrupt-parent = gic;
+   interrupts = 0 77 0x4;
+   };
+};
+
+usbhshost {
+   port1_mode = 1; /* OMAP_EHCI_PORT_MODE_PHY */
+   port2_mode = 2; /* OMAP_EHCI_PORT_MODE_TLL */
+   port3_mode = 1; /* OMAP_EHCI_PORT_MODE_PHY */
+};
+
+usbhsehci {
+   phy = hsusb1_phy 0 hsusb3_phy;
+};
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index f8ed08e..0f67856 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -1,8 +1,9 @@
  /**
   * omap-usb-host.c - The USBHS core driver for OMAP EHCI  OHCI
   *
- * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2011-2013 Texas Instruments Incorporated - http://www.ti.com
   * Author: Keshava Munegowda keshava_mgo...@ti.com
+ * Author: Roger Quadros rog...@ti.com
   *
   * This program is free software: you can redistribute it and/or modify
   * it under the terms of the GNU General Public License version 2  of
@@ -27,6 +28,8 @@
  #include linux/platform_device.h
  #include linux/platform_data/usb-omap.h
  #include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_platform.h

  #include omap-usb.h

@@ -464,6 +467,37 @@ static void omap_usbhs_init(struct device *dev)
pm_runtime_put_sync(dev);
  }

+static int usbhs_omap_get_dt_pdata(struct device_node *node,
+   struct usbhs_omap_platform_data *pdata)
+{
+   int ret, i;
+
+   ret = of_property_read_u32(node, nports, pdata-nports);
+   if (ret)
+   pdata-nports = 0;
+
+   /* get port modes */
+   for (i = 0; i  OMAP3_HS_USB_PORTS; i++) {
+   char prop[11];
+
+   snprintf(prop, sizeof(prop), port%d_mode, i + 1);
+   ret = of_property_read_u32(node, prop, pdata-port_mode[i]);
+   if (ret)
+   pdata-port_mode[i] = OMAP_USBHS_PORT_MODE_UNUSED;
+   }
+
+   /* get flags */
+   pdata-single_ulpi_bypass = of_property_read_bool(node,
+   single_ulpi_bypass);
+   return 0;
+}
+
+static struct of_device_id usbhs_child_match_table[] __initdata = {
+   { .compatible = ti,omap-ehci, },
+   { .compatible = ti,omap-ohci, },
+   { }
+};
+
  /**
   * usbhs_omap_probe - initialize TI-based HCDs
   *
@@ -479,6 +513,21 @@ static int usbhs_omap_probe(struct platform_device *pdev)
int i;
boolneed_logic_fck;

+   if (dev-of_node) {
+

Re: [PATCH 10/13] ARM: dts: OMAP4: Add HS USB Host IP nodes


On Monday 04 February 2013 09:28 PM, Roger Quadros wrote:

Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.

Signed-off-by: Roger Quadros rog...@ti.com
---
  arch/arm/boot/dts/omap4.dtsi |   30 ++
  1 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..3429280 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -529,5 +529,35 @@
ti,hwmods = timer11;
ti,timer-pwm;
};
+
+   usbhstll: usbhstll@0x4a062000 {
+   compatible = ti,usbhs-tll;
+   reg = 0x4a062000 0x1000;
+   interrupts = 0 78 0x4;
+   ti,hwmods = usb_tll_hs;
+   };
+
+   usbhshost: usbhshost@0x4a064000 {
+   compatible = ti,usbhs-host;
+   reg = 0x4a064000 0x800;
+   ti,hwmods = usb_host_hs;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+
+   usbhsohci: ohci@0x4a064800 {
+   compatible = ti,omap3-ohci, usb-ohci;
+   reg = 0x4a064800 0x400;
+   interrupt-parent = gic;


Just curious.. Were you facing issues if you are not having 
interrupt-parent here? It's also missing in your dt node usbhstll.


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 01/13] usb: phy: nop: Add device tree support and binding information

Hi,

On Mon, Feb 04, 2013 at 05:58:48PM +0200, Roger Quadros wrote:
 The PHY clock, clock rate, VCC regulator and RESET regulator
 can now be provided via device tree.
 
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  .../devicetree/bindings/usb/usb-nop-xceiv.txt  |   34 
 
  drivers/usb/otg/nop-usb-xceiv.c|   31 ++
  2 files changed, 65 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
 
 diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt 
 b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
 new file mode 100644
 index 000..d7e2726
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
 @@ -0,0 +1,34 @@
 +USB NOP PHY
 +
 +Required properties:
 +- compatible: should be usb-nop-xceiv
 +
 +Optional properties:
 +- clocks: phandle to the PHY clock. Use as per Documentation/devicetree
 +  /bindings/clock/clock-bindings.txt
 +  This property is required if clock-frequency is specified.
 +
 +- clock-names: Should be main_clk
 +
 +- clock-frequency: the clock frequency (in Hz) that the PHY clock must
 +  be configured to.
 +
 +- vcc-supply: phandle to the regulator that provides RESET to the PHY.
 +
 +- reset-supply: phandle to the regulator that provides power to the PHY.
 +
 +Example:
 +
 + hsusb1_phy {
 + compatible = usb-nop-xceiv;
 + clock-frequency = 1920;
 + clocks = osc 0;
 + clock-names = main_clk;
 + vcc-supply = hsusb1_vcc_regulator;
 + reset-supply = hsusb1_reset_regulator;
 + };
 +
 +hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator
 +and expects that clock to be configured to 19.2MHz by the NOP PHY driver.
 +hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset_regulator
 +controls RESET.
 diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
 index ac027a1..adbb7ab 100644
 --- a/drivers/usb/otg/nop-usb-xceiv.c
 +++ b/drivers/usb/otg/nop-usb-xceiv.c
 @@ -34,6 +34,7 @@
  #include linux/slab.h
  #include linux/clk.h
  #include linux/regulator/consumer.h
 +#include linux/of.h
  
  struct nop_usb_xceiv {
   struct usb_phy  phy;
 @@ -138,8 +139,19 @@ static int nop_set_host(struct usb_otg *otg, struct 
 usb_bus *host)
   return 0;
  }
  
 +static void nop_xeiv_get_dt_pdata(struct device *dev,

asking to remove, but xeiv != xceiv :-)

 + struct nop_usb_xceiv_platform_data *pdata)
 +{
 + struct device_node *node = dev-of_node;
 + u32 clk_rate;
 +
 + if (!of_property_read_u32(node, clock-frequency, clk_rate))
 + pdata-clk_rate = clk_rate;
 +}
 +
  static int nop_usb_xceiv_probe(struct platform_device *pdev)
  {
 + struct device *dev = pdev-dev;
   struct nop_usb_xceiv_platform_data *pdata = pdev-dev.platform_data;
   struct nop_usb_xceiv*nop;
   enum usb_phy_type   type = USB_PHY_TYPE_USB2;
 @@ -153,6 +165,17 @@ static int nop_usb_xceiv_probe(struct platform_device 
 *pdev)
   if (!nop-phy.otg)
   return -ENOMEM;
  
 + if (dev-of_node) {
 + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
 + if (!pdata) {
 + dev_err(dev, Memory allocation failure\n);
 + return -ENOMEM;
 + }
 + nop_xeiv_get_dt_pdata(dev, pdata);

actually, I would prefer to not create pdata at all. I mean, ideally
pdata would be used to initialize fields in your own structure, so first
move clk_rate to your own private structure, copy pdata's clk_rate value
to that, then you don't need this hackery when using DT.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 10/13] ARM: dts: OMAP4: Add HS USB Host IP nodes