Re: [PATCH 0/4] TI LCDC DRM driver

[Sascha Hauer]

Hi Rob,

On Tue, Jan 22, 2013 at 04:36:21PM -0600, Rob Clark wrote:
> 
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/i2c/Makefile   |   3 +
>  drivers/gpu/drm/i2c/tda998x_drv.c  | 908 
> +
>  drivers/gpu/drm/tilcdc/Kconfig |  25 +
>  drivers/gpu/drm/tilcdc/Makefile|  10 +
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c   | 597 ++
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c| 611 ++
>  drivers/gpu/drm/tilcdc/tilcdc_drv.h| 159 ++
>  drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 443 
>  drivers/gpu/drm/tilcdc/tilcdc_panel.h  |  26 +
>  drivers/gpu/drm/tilcdc/tilcdc_regs.h   | 154 ++
>  drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 380 ++
>  drivers/gpu/drm/tilcdc/tilcdc_slave.h  |  26 +
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 423 +++
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.h |  26 +
>  16 files changed, 3794 insertions(+)
>  create mode 100644 drivers/gpu/drm/i2c/tda998x_drv.c
>  create mode 100644 drivers/gpu/drm/tilcdc/Kconfig
>  create mode 100644 drivers/gpu/drm/tilcdc/Makefile
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_crtc.c
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.c
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.h
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.c
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.h
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_regs.h
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.h

I'm missing Documentation/devicetree/bindings/drm/tilcdc/ in the
diffstat. This is required for adding devicetree bindings.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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/4] drm/i2c: nxp-tda998x (v2)

[Koen Kooi]

Op 22 jan. 2013, om 23:36 heeft Rob Clark  het volgende 
geschreven:

> Driver for the NXP TDA998X i2c hdmi encoder slave.
> 
> v1: original
> v2: fix npix/nline programming
> 
> Signed-off-by: Rob Clark 

Tested on a  beaglebone-black:

Tested-by: Koen Kooi 

--
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/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)

[Koen Kooi]

Op 22 jan. 2013, om 23:36 heeft Rob Clark  het volgende 
geschreven:

> A simple DRM/KMS driver for the TI LCD Controller found in various
> smaller TI parts (AM33xx, OMAPL138, etc).  This driver uses the
> CMA helpers.  Currently only the TFP410 DVI encoder is supported
> (tested with beaglebone + DVI cape).  There are also various LCD
> displays, for which support can be added (as I get hw to test on),
> and an external i2c HDMI encoder found on some boards.
> 
> The display controller supports a single CRTC.  And the encoder+
> connector are split out into sub-devices.  Depending on which LCD
> or external encoder is actually present, the appropriate output
> module(s) will be loaded.
> 
> v1: original
> v2: fix fb refcnting and few other cleanups
> v3: get +/- vsync/hsync from timings rather than panel-info, add
>option DT max-bandwidth field so driver doesn't attempt to
>pick a display mode with too high memory bandwidth, and other
>small cleanups
> 
> Signed-off-by: Rob Clark 

Tested on a beaglebone and beaglebone-black:

Tested-by: Koen Kooi --
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/3] ARM: dts: AM33XX: Add ELM node

[Philip, Avinash]

On Tue, Jan 22, 2013 at 02:17:38, Peter Korsgaard wrote:
> > "Philip" == Philip Avinash  writes:
> 
>  Philip> From: "Philip, Avinash" 
>  Philip> Add ELM data node to AM33XX device tree file.
> 
>  Philip> Signed-off-by: Philip Avinash 
>  Philip> ---
>  Philip>  arch/arm/boot/dts/am33xx.dtsi |8 
>  Philip>  1 file changed, 8 insertions(+)
> 
>  Philip> diff --git a/arch/arm/boot/dts/am33xx.dtsi 
> b/arch/arm/boot/dts/am33xx.dtsi
>  Philip> index c2f14e8..eaef5e7 100644
>  Philip> --- a/arch/arm/boot/dts/am33xx.dtsi
>  Philip> +++ b/arch/arm/boot/dts/am33xx.dtsi
>  Philip> @@ -385,5 +385,13 @@
>  Philip>  mac-address = [ 00 00 00 00 00 00 ];
>  Philip>  };
>  Philip>  };
>  Philip> +
>  Philip> +elm: elm@4808 {
>  Philip> +compatible  = "ti,am33xx-elm";
> 
> Please drop the  after compatible.

I will replace with space and submit another version

> 
> Other than that it looks goood.
> 
> Acked-by: Peter Korsgaard 

Thanks
Avinash

> 
> -- 
> Bye, Peter Korsgaard
> 

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

RE: [PATCH 2/3] ARM: dts: AM33XX: Add GPMC node

[Philip, Avinash]

On Tue, Jan 22, 2013 at 02:31:53, Peter Korsgaard wrote:
> > "Philip" == Philip Avinash  writes:
> 
>  Philip> From: "Philip, Avinash" 
>  Philip> Add GPMC data node to AM33XX device tree file.
> 
>  Philip> Signed-off-by: Philip Avinash 
>  Philip> ---
>  Philip>  arch/arm/boot/dts/am33xx.dtsi |   12 
>  Philip>  1 file changed, 12 insertions(+)
> 
>  Philip> diff --git a/arch/arm/boot/dts/am33xx.dtsi 
> b/arch/arm/boot/dts/am33xx.dtsi
>  Philip> index eaef5e7..f4209d8 100644
>  Philip> --- a/arch/arm/boot/dts/am33xx.dtsi
>  Philip> +++ b/arch/arm/boot/dts/am33xx.dtsi
>  Philip> @@ -393,5 +393,17 @@
>  Philip>  ti,hwmods = "elm";
>  Philip>  status = "disabled";
>  Philip>  };
>  Philip> +
>  Philip> +gpmc: gpmc@5000 {
>  Philip> +compatible = "ti,am3352-gpmc";
>  Philip> +ti,hwmods = "gpmc";
>  Philip> +reg = <0x5000 0x2000>;
>  Philip> +interrupts = <100>;
>  Philip> +num-cs = <8>;
> 
> Next to Jan's comment about am335x having 7 cs signals, I just realized
> the difference in compatible string between the gpmc and elm. The gpmc
> refers to a real device (which is afaik how it should be done), but the
> elm compatible is simply ti,am33xx-elm.
> 
> Presumably it should have been ti,am3352-elm in the binding instead?

I thought of following the file name convention. I will correct to 
"ti,am3352-elm"

> 
> Other than that it looks fine.
> 
> Acked-by: Peter Korsgaard 

Thanks
Avinash

> 
> -- 
> Bye, Peter Korsgaard
> 

--
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 6/6] OF: Introduce DT overlay support.

[David Gibson]

On Tue, Jan 22, 2013 at 01:08:04PM +0200, Pantelis Antoniou wrote:
> Hi
> 
> On Jan 22, 2013, at 5:50 AM, David Gibson wrote:
> 
> > On Fri, Jan 04, 2013 at 09:31:10PM +0200, Pantelis Antoniou wrote:
> >> Introduce DT overlay support.
> >> Using this functionality it is possible to dynamically overlay a part of
> >> the kernel's tree with another tree that's been dynamically loaded.
> >> It is also possible to remove node and properties.
> >> 
> >> Signed-off-by: Pantelis Antoniou 
> >> ---
> >> Documentation/devicetree/overlay-notes.txt | 179 +++
> >> drivers/of/Kconfig |  10 +
> >> drivers/of/Makefile|   1 +
> >> drivers/of/overlay.c   | 831 
> >> +
> >> include/linux/of.h | 107 
> >> 5 files changed, 1128 insertions(+)
> >> create mode 100644 Documentation/devicetree/overlay-notes.txt
> >> create mode 100644 drivers/of/overlay.c
> >> 
> >> diff --git a/Documentation/devicetree/overlay-notes.txt 
> >> b/Documentation/devicetree/overlay-notes.txt
> >> new file mode 100644
> >> index 000..5289cbb
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/overlay-notes.txt
> >> @@ -0,0 +1,179 @@
> >> +Device Tree Overlay Notes
> >> +-
> >> +
> >> +This document describes the implementation of the in-kernel
> >> +device tree overlay functionality residing in drivers/of/overlay.c and is 
> >> a
> >> +companion document to Documentation/devicetree/dt-object-internal.txt[1] &
> >> +Documentation/devicetree/dynamic-resolution-notes.txt[2]
> >> +
> >> +How overlays work
> >> +-
> >> +
> >> +A Device Tree's overlay purpose is to modify the kernel's live tree, and
> >> +have the modification affecting the state of the the kernel in a way that
> >> +is reflecting the changes.
> > 
> > Um.. I'm having a great deal of trouble parsing that sentence.
> > 
> >> +Since the kernel mainly deals with devices, any new device node that 
> >> result
> >> +in an active device should have it created while if the device node is 
> >> either
> >> +disabled or removed all together, the affected device should be 
> >> deregistered.
> >> +
> >> +Lets take an example where we have a foo board with the following base 
> >> tree
> >> +which is taken from [1].
> >> +
> >> + foo.dts 
> >> -
> >> +  /* FOO platform */
> >> +  / {
> >> +  compatible = "corp,foo";
> >> +
> >> +  /* shared resources */
> >> +  res: res {
> >> +  };
> >> +
> >> +  /* On chip peripherals */
> >> +  ocp: ocp {
> >> +  /* peripherals that are always instantiated */
> >> +  peripheral1 { ... };
> >> +  }
> >> +  };
> >> + foo.dts 
> >> -
> >> +
> >> +The overlay bar.dts, when loaded (and resolved as described in [2]) should
> >> +
> >> + bar.dts 
> >> -
> >> +/plugin/; /* allow undefined label references and record them */
> >> +/ {
> >> +  /* various properties for loader use; i.e. part id etc. */
> >> +  fragment@0 {
> >> +  target = <&ocp>;
> >> +  __overlay__ {
> >> +  /* bar peripheral */
> >> +  bar {
> >> +  compatible = "corp,bar";
> >> +  ... /* various properties and child nodes */
> >> +  }
> >> +  };
> >> +  };
> >> +};
> >> + bar.dts 
> >> -
> >> +
> >> +result in foo+bar.dts
> >> +
> >> + foo+bar.dts 
> >> -
> >> +  /* FOO platform + bar peripheral */
> >> +  / {
> >> +  compatible = "corp,foo";
> >> +
> >> +  /* shared resources */
> >> +  res: res {
> >> +  };
> >> +
> >> +  /* On chip peripherals */
> >> +  ocp: ocp {
> >> +  /* peripherals that are always instantiated */
> >> +  peripheral1 { ... };
> >> +
> >> +  /* bar peripheral */
> >> +  bar {
> >> +  compatible = "corp,bar";
> >> +  ... /* various properties and child nodes */
> >> +  }
> >> +  }
> >> +  };
> >> + foo+bar.dts 
> >> -
> >> +
> >> +As a result of the the overlay, a new device node (bar) has been created
> >> +so a bar platform device will be registered and if a matching device 
> >> driver
> >> +is loaded the device will be created as expected.
> > 
> > Hrm.  This all seems rather complicated.  Maybe it needs to be, but
> > I'm not entirely convinced yet.
> > 
> > One other point - both of these patches are assuming that the ov

Re: [PATCH v1 0/6] USB: Add support for multiple PHYs of same type

[kishon]

On Tuesday 22 January 2013 10:32 PM, Koen Kooi wrote:


Op 22 jan. 2013, om 17:16 heeft kishon  het volgende geschreven:


Hi,

On Tuesday 22 January 2013 09:15 PM, kishon wrote:

On Tuesday 22 January 2013 09:11 PM, Koen Kooi wrote:


Op 22 jan. 2013, om 10:58 heeft Kishon Vijay Abraham I 
het volgende geschreven:


This patch series adds support for adding multiple PHY's (of same type).
The binding information has to be present in the PHY library (otg.c) in
order for it to return the appropriate PHY whenever the USB controller
request for the PHY. So added a new API usb_bind_phy() to pass the
binding
information. This API should be called by platform specific
initialization
code.

So the binding should be done something like
usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto"); specifying
the USB
controller device name, index, and the PHY device name.
I have done this binding for OMAP platforms, but it should be done for
all the platforms.

After this design, the phy can be got by passing the USB controller
device
pointer and the index.

Developed this patch series on
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv
after applying "usb: musb: add driver for control module" patch series
and "ARM: dts: omap: add dt data for MUSB"

Did basic enumeration testing in omap4 panda and omap3 beagle.


With this patchset USB completely breaks on am33xx beaglebone, is that
intended?

Not really.
Does am33xx makes use of omap2430.c? Which PHY does am33xx uses?


I figured out it uses drivers/usb/musb/musb_dsps.c (So it doesn't use 
omap2430.c). I think it uses TWL4030_USB (TPS659x0) as PHY.


Actually it uses nop-phy as a phy, which is missing from 
arch/arm/boot/dts/am33xx.dtsi, so mainline is already broken. But adding the 
nop-phy to the DT is easy enough to patch in locally.


Cool. You can add your patch after applying this series then. (I'll post 
a new version addressing the comments in this series.)


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 5/6] OF: Introduce Device Tree resolve support.

[David Gibson]

On Tue, Jan 22, 2013 at 01:06:09PM +0200, Pantelis Antoniou wrote:
> Hi
> 
> On Jan 22, 2013, at 6:05 AM, David Gibson wrote:
> 
> > On Mon, Jan 21, 2013 at 12:59:15PM +0200, Pantelis Antoniou wrote:
> >> Hi David
> >> 
> >> On Jan 21, 2013, at 6:48 AM, David Gibson wrote:
> >> 
> >>> On Fri, Jan 04, 2013 at 09:31:09PM +0200, Pantelis Antoniou wrote:
>  Introduce support for dynamic device tree resolution.
>  Using it, it is possible to prepare a device tree that's
>  been loaded on runtime to be modified and inserted at the kernel
>  live tree.
>  
>  Signed-off-by: Pantelis Antoniou 
>  ---
>  .../devicetree/dynamic-resolution-notes.txt|  25 ++
>  drivers/of/Kconfig |   9 +
>  drivers/of/Makefile|   1 +
>  drivers/of/resolver.c  | 394 
>  +
>  include/linux/of.h |  17 +
>  5 files changed, 446 insertions(+)
>  create mode 100644 Documentation/devicetree/dynamic-resolution-notes.txt
>  create mode 100644 drivers/of/resolver.c
>  
>  diff --git a/Documentation/devicetree/dynamic-resolution-notes.txt 
>  b/Documentation/devicetree/dynamic-resolution-notes.txt
>  new file mode 100644
>  index 000..0b396c4
>  --- /dev/null
>  +++ b/Documentation/devicetree/dynamic-resolution-notes.txt
>  @@ -0,0 +1,25 @@
>  +Device Tree Dynamic Resolver Notes
>  +--
>  +
>  +This document describes the implementation of the in-kernel
>  +Device Tree resolver, residing in drivers/of/resolver.c and is a
>  +companion document to Documentation/devicetree/dt-object-internal.txt[1]
>  +
>  +How the resolver works
>  +--
>  +
>  +The resolver is given as an input an arbitrary tree compiled with the
>  +proper dtc option and having a /plugin/ tag. This generates the
>  +appropriate __fixups__ & __local_fixups__ nodes as described in [1].
>  +
>  +In sequence the resolver works by the following steps:
>  +
>  +1. Get the maximum device tree phandle value from the live tree + 1.
>  +2. Adjust all the local phandles of the tree to resolve by that amount.
>  +3. Using the __local__fixups__ node information adjust all local 
>  references
>  +   by the same amount.
>  +4. For each property in the __fixups__ node locate the node it 
>  references
>  +   in the live tree. This is the label used to tag the node.
>  +5. Retrieve the phandle of the target of the fixup.
>  +5. For each fixup in the property locate the node:property:offset 
>  location
>  +   and replace it with the phandle value.
> >>> 
> >>> Hrm.  So, I'm really still not convinced by this approach.
> >>> 
> >>>   First, I think it's unwise to allow overlays to change
> >>> essentially anything in the base tree, rather than having the base
> >>> tree define sockets of some sort where things can be attached.
> >>> 
> >> 
> >> One could say that the labels define the sockets. It's not just things
> >> to be attached, properties might have to change, or something more complex,
> >> as we've found out in practice.
> > 
> > Hrm.  I know a number of these have come up previously in that big
> > thread, but can you summarise some of these cases here.  If things
> > need modification in the base tree that still seems to me like the
> > base tree hasn't properly described the socket arrangement (I realise
> > that allowing such descriptions may require extensions to some of our
> > device tree conventions).
> > 
> 
> It would be pointless to number all the use-cases that Grant put in that
> long document, but I can summarize the cases that we've seen on the bone.
> 
> * Addition of child device nodes to the ocp node, creates new platform
> devices of various kind (audio/video/pwms/timers) - almost any kind of
> platform device that the SoC supports. Removing the overlay unregisters
> the devices (but precious few drivers support that cleanly ATM). Since
> the capes don't support hotplug that's not a big deal.

Ok, that's just adding nodes, which is straightforward.

> * Addition of pinctrl configuration nodes.

Ok, do you know where I can look to see how the pinctrl stuff works?

> * Addition of i2c/spi etc device nodes and modification of the parent's
> node status property to "okay",

Ok.  I'm assuming this is basically just to enable the bus controller
which was previously disabled because it had nothing attached to it?

> creates the bus platform device & registers
> the devices on the bus. Slight complication with i2c client devices which
> are not platform devices need special handling.

And this part is again just adding nodes.

> * Modification of configuration parameters of a disabled device and subsequent
> enablement. 

What sorts of modification are necessary to th

Re: [PATCH v5 00/14] DMA Engine support for AM33XX

[Mark Brown]

On Tue, Jan 22, 2013 at 09:26:34PM +0530, Sekhar Nori wrote:
> On 1/16/2013 2:02 AM, Matt Porter wrote:

> > This series adds DMA Engine support for AM33xx, which uses
> > an EDMA DMAC. The EDMA DMAC has been previously supported by only
> > a private API implementation (much like the situation with OMAP
> > DMA) found on the DaVinci family of SoCs.

> Will you take this series through the OMAP tree? Only 1/14 touches
> mach-davinci and I am mostly okay with it except some changes I just
> requested Matt to make in another thread.

Is this series somewhere near actually getting merged then? It seemed
like there was lots of stuff going on.


signature.asc
Description: Digital signature

Re: [PATCH 0/2] OMAP3 ISP: Simplify clock usage

[Laurent Pinchart]

Hi Paul,

On Tuesday 22 January 2013 02:57:22 Paul Walmsley wrote:
> On Mon, 21 Jan 2013, Laurent Pinchart wrote:
> > OK. The omap3isp patch can go through Paul's tree as well, it won't
> > conflict with other changes to the driver in this merge window.
> > 
> > Paul, can you take both patches together ? If so I'll send you a pull
> > request.
>
> Yes I'll take them, as long as they won't cause conflicts outside of
> arch/arm/mach-omap2. Otherwise the OMAP3 ISP patch should wait until the
> early v3.9-rc integration fixes timeframe.

There's currently no conflict with the other OMAP3 ISP patches that I intend 
to push to v3.9.

The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619:

  Linux 3.8-rc4 (2013-01-17 19:25:45 -0800)

are available in the git repository at:

  git://linuxtv.org/pinchartl/media.git omap3isp/clock

for you to fetch changes up to 6d1aa02f10497b138e01ebe6eafabd6071729334:

  omap3isp: Set cam_mclk rate directly (2013-01-23 00:44:04 +0100)


Laurent Pinchart (2):
  ARM: OMAP3: clock: Back-propagate rate change from cam_mclk to dpll4_m5
  omap3isp: Set cam_mclk rate directly

 arch/arm/mach-omap2/cclock3xxx_data.c | 10 +-
 drivers/media/platform/omap3isp/isp.c | 18 ++
 drivers/media/platform/omap3isp/isp.h |  8 +++-
 3 files changed, 14 insertions(+), 22 deletions(-)

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)

[Daniel Vetter]

On Tue, Jan 22, 2013 at 04:36:22PM -0600, Rob Clark wrote:
> A simple DRM/KMS driver for the TI LCD Controller found in various
> smaller TI parts (AM33xx, OMAPL138, etc).  This driver uses the
> CMA helpers.  Currently only the TFP410 DVI encoder is supported
> (tested with beaglebone + DVI cape).  There are also various LCD
> displays, for which support can be added (as I get hw to test on),
> and an external i2c HDMI encoder found on some boards.
> 
> The display controller supports a single CRTC.  And the encoder+
> connector are split out into sub-devices.  Depending on which LCD
> or external encoder is actually present, the appropriate output
> module(s) will be loaded.
> 
> v1: original
> v2: fix fb refcnting and few other cleanups
> v3: get +/- vsync/hsync from timings rather than panel-info, add
> option DT max-bandwidth field so driver doesn't attempt to
> pick a display mode with too high memory bandwidth, and other
> small cleanups
> 
> Signed-off-by: Rob Clark 

Ok, read through it, looks nice. No idea whether this should use the panel
stuff, but since no-one else does who cares. A few nits and questions
below. Was a nice reading to learn about kfifo and the runtime power
stuff.

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/tilcdc/Kconfig |  10 +
>  drivers/gpu/drm/tilcdc/Makefile|   8 +
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c   | 597 
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c| 605 
> +
>  drivers/gpu/drm/tilcdc/tilcdc_drv.h| 159 +
>  drivers/gpu/drm/tilcdc/tilcdc_regs.h   | 154 +
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 423 +++
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.h |  26 ++
>  10 files changed, 1985 insertions(+)
>  create mode 100644 drivers/gpu/drm/tilcdc/Kconfig
>  create mode 100644 drivers/gpu/drm/tilcdc/Makefile
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_crtc.c
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.c
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.h
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_regs.h
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
>  create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.h
> 

[cut]

> +struct tilcdc_crtc {
> + struct drm_crtc base;
> +
> + const struct tilcdc_panel_info *info;
> + uint32_t dirty;
> + dma_addr_t start, end;
> + struct drm_pending_vblank_event *event;
> + int dpms;
> + wait_queue_head_t frame_done_wq;
> + bool frame_done;
> +
> + /* fb currently set to scanout 0/1: */
> + struct drm_framebuffer *scanout[2];
> +
> + /* for deferred fb unref's: */
> + DECLARE_KFIFO_PTR(unref_fifo, struct drm_framebuffer *);
> + struct work_struct work;
> +};
> +#define to_tilcdc_crtc(x) container_of(x, struct tilcdc_crtc, base)
> +
> +static void unref_worker(struct work_struct *work)
> +{
> + struct tilcdc_crtc *tilcdc_crtc = container_of(work, struct 
> tilcdc_crtc, work);
> + struct drm_device *dev = tilcdc_crtc->base.dev;
> + struct drm_framebuffer *fb;
> +
> + mutex_lock(&dev->mode_config.mutex);
> + while (kfifo_get(&tilcdc_crtc->unref_fifo, &fb))
> + drm_framebuffer_unreference(fb);
> + mutex_unlock(&dev->mode_config.mutex);

Hm, just learned about the kfifo api. It looks like the locking here still
works even with the new modeset locking, since kfifo explicitly allows
concurrent readers and writers without locking, as long as there's only on
of each kind. But maybe switch over to crtc->mutex to make things less
tricky.

Also, kfifo seems to have a new api which allows embedding of the kfifo
thing and needs to be used with kfifo_in/out.

[cut]

> +static void update_scanout(struct drm_crtc *crtc)
> +{
> + struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
> + struct drm_device *dev = crtc->dev;
> + struct drm_framebuffer *fb = crtc->fb;
> + struct drm_gem_cma_object *gem;
> + unsigned int depth, bpp;
> +
> + drm_fb_get_bpp_depth(fb->pixel_format, &depth, &bpp);
> + gem = drm_fb_cma_get_gem_obj(fb, 0);
> +
> + tilcdc_crtc->start = gem->paddr + fb->offsets[0] +
> + (crtc->y * fb->pitches[0]) + (crtc->x * bpp/8);
> +
> + tilcdc_crtc->end = tilcdc_crtc->start +
> + (crtc->mode.vdisplay * fb->pitches[0]);
> +
> + if (tilcdc_crtc->dpms == DRM_MODE_DPMS_ON) {
> + /* already enabled, so just mark the frames that need
> +  * updating and they will be updated on vblank:
> +  */
> + tilcdc_crtc->dirty |= LCDC_END_OF_FRAME0 | LCDC_END_OF_FRAME1;
> + drm_vblank_get(dev, 0);
> + } else {
> + /* not enabled yet, so update registers immediately: */
> + set_scanout(crtc, 0);
> + set_scanout(crtc, 1

[PATCH 4/4] drm/tilcdc: add support for LCD panels (v4)

[Rob Clark]

Add an output panel driver for LCD panels.  Tested with LCD3 cape on
beaglebone.

v1: original
v2: s/of_find_node_by_name()/of_get_child_by_name()/ from Pantelis
Antoniou
v3: add backlight support
v4: rebase to latest of video timing helpers

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/tilcdc/Kconfig|   3 +
 drivers/gpu/drm/tilcdc/Makefile   |   1 +
 drivers/gpu/drm/tilcdc/tilcdc_drv.c   |   3 +
 drivers/gpu/drm/tilcdc/tilcdc_panel.c | 443 ++
 drivers/gpu/drm/tilcdc/tilcdc_panel.h |  26 ++
 5 files changed, 476 insertions(+)
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.h

diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
index 99beca2..f468b2b 100644
--- a/drivers/gpu/drm/tilcdc/Kconfig
+++ b/drivers/gpu/drm/tilcdc/Kconfig
@@ -4,6 +4,9 @@ config DRM_TILCDC
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
+   select OF_VIDEOMODE
+   select OF_DISPLAY_TIMING
+   select BACKLIGHT_CLASS_DEVICE
help
  Choose this option if you have an TI SoC with LCDC display
  controller, for example AM33xx in beagle-bone, DA8xx, or
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index aa9097e..deda656 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -4,6 +4,7 @@ tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
tilcdc_slave.o \
+   tilcdc_panel.o \
tilcdc_drv.o
 
 obj-$(CONFIG_DRM_TILCDC)   += tilcdc.o
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index ca76dbe..d10858c 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -21,6 +21,7 @@
 #include "tilcdc_regs.h"
 #include "tilcdc_tfp410.h"
 #include "tilcdc_slave.h"
+#include "tilcdc_panel.h"
 
 #include "drm_fb_helper.h"
 
@@ -589,6 +590,7 @@ static int __init tilcdc_drm_init(void)
DBG("init");
tilcdc_tfp410_init();
tilcdc_slave_init();
+   tilcdc_panel_init();
return platform_driver_register(&tilcdc_platform_driver);
 }
 
@@ -597,6 +599,7 @@ static void __exit tilcdc_drm_fini(void)
DBG("fini");
tilcdc_tfp410_fini();
tilcdc_slave_fini();
+   tilcdc_panel_fini();
platform_driver_unregister(&tilcdc_platform_driver);
 }
 
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
new file mode 100644
index 000..a3c7fe93
--- /dev/null
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -0,0 +1,443 @@
+/*
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "tilcdc_drv.h"
+
+struct panel_module {
+   struct tilcdc_module base;
+   struct tilcdc_panel_info *info;
+   struct display_timings *timings;
+   struct backlight_device *backlight;
+};
+#define to_panel_module(x) container_of(x, struct panel_module, base)
+
+
+/*
+ * Encoder:
+ */
+
+struct panel_encoder {
+   struct drm_encoder base;
+   struct panel_module *mod;
+};
+#define to_panel_encoder(x) container_of(x, struct panel_encoder, base)
+
+
+static void panel_encoder_destroy(struct drm_encoder *encoder)
+{
+   struct panel_encoder *panel_encoder = to_panel_encoder(encoder);
+   drm_encoder_cleanup(encoder);
+   kfree(panel_encoder);
+}
+
+static void panel_encoder_dpms(struct drm_encoder *encoder, int mode)
+{
+   struct panel_encoder *panel_encoder = to_panel_encoder(encoder);
+   struct backlight_device *backlight = panel_encoder->mod->backlight;
+
+   if (!backlight)
+   return;
+
+   backlight->props.power = mode == DRM_MODE_DPMS_ON
+? FB_BLANK_UNBLANK : FB_BLANK_POWERDOWN;
+   backlight_update_status(backlight);
+}
+
+static bool panel_encoder_mode_fixup(struct drm_encoder *encoder,
+   const struct drm_display_mode *mode,
+   struct drm_display_mode *adjusted_mode)
+{
+   /* nothing needed */
+   return true;
+}
+
+static void panel_encoder_prepare(struct drm_encoder *encoder)
+{
+   struct panel_encoder *panel_encoder = to_panel_encoder(encoder);
+   panel_encoder_dpms(encoder, D

[PATCH 3/4] drm/tilcdc: add encoder slave

[Rob Clark]

Add output panel driver for i2c encoder slaves.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/tilcdc/Kconfig|  12 ++
 drivers/gpu/drm/tilcdc/Makefile   |   1 +
 drivers/gpu/drm/tilcdc/tilcdc_drv.c   |   5 +-
 drivers/gpu/drm/tilcdc/tilcdc_slave.c | 380 ++
 drivers/gpu/drm/tilcdc/tilcdc_slave.h |  26 +++
 5 files changed, 423 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h

diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
index ee9b592..99beca2 100644
--- a/drivers/gpu/drm/tilcdc/Kconfig
+++ b/drivers/gpu/drm/tilcdc/Kconfig
@@ -8,3 +8,15 @@ config DRM_TILCDC
  Choose this option if you have an TI SoC with LCDC display
  controller, for example AM33xx in beagle-bone, DA8xx, or
  OMAP-L1xx.  This driver replaces the FB_DA8XX fbdev driver.
+
+menu "I2C encoder or helper chips"
+   depends on DRM && DRM_KMS_HELPER && I2C
+
+config DRM_I2C_NXP_TDA998X
+   tristate "NXP Semiconductors TDA998X HDMI encoder"
+   default m if DRM_TILCDC
+   help
+ Support for NXP Semiconductors TDA998X HDMI encoders.
+
+endmenu
+
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index 1359cc2..aa9097e 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -3,6 +3,7 @@ ccflags-y := -Iinclude/drm -Werror
 tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
+   tilcdc_slave.o \
tilcdc_drv.o
 
 obj-$(CONFIG_DRM_TILCDC)   += tilcdc.o
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index cf1fddc..ca76dbe 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -20,6 +20,7 @@
 #include "tilcdc_drv.h"
 #include "tilcdc_regs.h"
 #include "tilcdc_tfp410.h"
+#include "tilcdc_slave.h"
 
 #include "drm_fb_helper.h"
 
@@ -587,6 +588,7 @@ static int __init tilcdc_drm_init(void)
 {
DBG("init");
tilcdc_tfp410_init();
+   tilcdc_slave_init();
return platform_driver_register(&tilcdc_platform_driver);
 }
 
@@ -594,10 +596,11 @@ static void __exit tilcdc_drm_fini(void)
 {
DBG("fini");
tilcdc_tfp410_fini();
+   tilcdc_slave_fini();
platform_driver_unregister(&tilcdc_platform_driver);
 }
 
-module_init(tilcdc_drm_init);
+late_initcall(tilcdc_drm_init);
 module_exit(tilcdc_drm_fini);
 
 MODULE_AUTHOR("Rob Clark 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "tilcdc_drv.h"
+
+struct slave_module {
+   struct tilcdc_module base;
+   struct i2c_adapter *i2c;
+};
+#define to_slave_module(x) container_of(x, struct slave_module, base)
+
+static const struct tilcdc_panel_info slave_info = {
+   .min_bpp= 16,
+   .max_bpp= 16,
+   .bpp= 16,
+   .ac_bias= 255,
+   .ac_bias_intrpt = 0,
+   .dma_burst_sz   = 16,
+   .fdd= 0x80,
+   .tft_alt_mode   = 0,
+   .stn_565_mode   = 0,
+   .mono_8bit_mode = 0,
+   .sync_edge  = 0,
+   .sync_ctrl  = 1,
+   .raster_order   = 0,
+};
+
+
+/*
+ * Encoder:
+ */
+
+struct slave_encoder {
+   struct drm_encoder_slave base;
+   struct slave_module *mod;
+};
+#define to_slave_encoder(x) container_of(to_encoder_slave(x), struct 
slave_encoder, base)
+
+static inline struct drm_encoder_slave_funcs *
+get_slave_funcs(struct drm_encoder *enc)
+{
+   return to_encoder_slave(enc)->slave_funcs;
+}
+
+static void slave_encoder_destroy(struct drm_encoder *encoder)
+{
+   struct slave_encoder *slave_encoder = to_slave_encoder(encoder);
+   if (get_slave_funcs(encoder))
+   get_slave_funcs(encoder)->destroy(encoder);
+   drm_encoder_cleanup(encoder);
+   kfree(slave_encoder);
+}
+
+static void slave_encoder_prepare(struct drm_encoder *encoder)
+{
+   drm_i2c_encoder_prepare(encoder);
+   tilcdc_crtc_set_panel_info(encoder->crtc, &slave_info);
+}
+
+static const struct drm_encoder_funcs slave_encoder_funcs = {
+   .destroy 

[PATCH 2/4] drm/i2c: nxp-tda998x (v2)

[Rob Clark]

Driver for the NXP TDA998X i2c hdmi encoder slave.

v1: original
v2: fix npix/nline programming

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/i2c/Makefile  |   3 +
 drivers/gpu/drm/i2c/tda998x_drv.c | 908 ++
 2 files changed, 911 insertions(+)
 create mode 100644 drivers/gpu/drm/i2c/tda998x_drv.c

diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
index 9286256..43aa33b 100644
--- a/drivers/gpu/drm/i2c/Makefile
+++ b/drivers/gpu/drm/i2c/Makefile
@@ -5,3 +5,6 @@ obj-$(CONFIG_DRM_I2C_CH7006) += ch7006.o
 
 sil164-y := sil164_drv.o
 obj-$(CONFIG_DRM_I2C_SIL164) += sil164.o
+
+tda998x-y := tda998x_drv.o
+obj-$(CONFIG_DRM_I2C_NXP_TDA998X) += tda998x.o
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
new file mode 100644
index 000..02054e8
--- /dev/null
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -0,0 +1,908 @@
+/*
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+
+#define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
+
+struct tda998x_priv {
+   struct i2c_client *cec;
+   uint16_t rev;
+   uint8_t current_page;
+   int dpms;
+};
+
+#define to_tda998x_priv(x)  ((struct tda998x_priv 
*)to_encoder_slave(x)->slave_priv)
+
+/* The TDA9988 series of devices use a paged register scheme.. to simplify
+ * things we encode the page # in upper bits of the register #.  To read/
+ * write a given register, we need to make sure CURPAGE register is set
+ * appropriately.  Which implies reads/writes are not atomic.  Fun!
+ */
+
+#define REG(page, addr) (((page) << 8) | (addr))
+#define REG2ADDR(reg)   ((reg) & 0xff)
+#define REG2PAGE(reg)   (((reg) >> 8) & 0xff)
+
+#define REG_CURPAGE   0xff/* write */
+
+
+/* Page 00h: General Control */
+#define REG_VERSION_LSB   REG(0x00, 0x00) /* read */
+#define REG_MAIN_CNTRL0   REG(0x00, 0x01) /* read/write */
+# define MAIN_CNTRL0_SR   (1 << 0)
+# define MAIN_CNTRL0_DECS (1 << 1)
+# define MAIN_CNTRL0_DEHS (1 << 2)
+# define MAIN_CNTRL0_CECS (1 << 3)
+# define MAIN_CNTRL0_CEHS (1 << 4)
+# define MAIN_CNTRL0_SCALER   (1 << 7)
+#define REG_VERSION_MSB   REG(0x00, 0x02) /* read */
+#define REG_SOFTRESET REG(0x00, 0x0a) /* write */
+# define SOFTRESET_AUDIO  (1 << 0)
+# define SOFTRESET_I2C_MASTER (1 << 1)
+#define REG_DDC_DISABLE   REG(0x00, 0x0b) /* read/write */
+#define REG_CCLK_ON   REG(0x00, 0x0c) /* read/write */
+#define REG_I2C_MASTERREG(0x00, 0x0d) /* read/write */
+# define I2C_MASTER_DIS_MM(1 << 0)
+# define I2C_MASTER_DIS_FILT  (1 << 1)
+# define I2C_MASTER_APP_STRT_LAT  (1 << 2)
+#define REG_INT_FLAGS_0   REG(0x00, 0x0f) /* read/write */
+#define REG_INT_FLAGS_1   REG(0x00, 0x10) /* read/write */
+#define REG_INT_FLAGS_2   REG(0x00, 0x11) /* read/write */
+# define INT_FLAGS_2_EDID_BLK_RD  (1 << 1)
+#define REG_ENA_VP_0  REG(0x00, 0x18) /* read/write */
+#define REG_ENA_VP_1  REG(0x00, 0x19) /* read/write */
+#define REG_ENA_VP_2  REG(0x00, 0x1a) /* read/write */
+#define REG_ENA_APREG(0x00, 0x1e) /* read/write */
+#define REG_VIP_CNTRL_0   REG(0x00, 0x20) /* write */
+# define VIP_CNTRL_0_MIRR_A   (1 << 7)
+# define VIP_CNTRL_0_SWAP_A(x)(((x) & 7) << 4)
+# define VIP_CNTRL_0_MIRR_B   (1 << 3)
+# define VIP_CNTRL_0_SWAP_B(x)(((x) & 7) << 0)
+#define REG_VIP_CNTRL_1   REG(0x00, 0x21) /* write */
+# define VIP_CNTRL_1_MIRR_C   (1 << 7)
+# define VIP_CNTRL_1_SWAP_C(x)(((x) & 7) << 4)
+# define VIP_CNTRL_1_MIRR_D   (1 << 3)
+# define VIP_CNTRL_1_SWAP_D(x)(((x) & 7) << 0)
+#define REG_VIP_CNTRL_2   REG(0x00, 0x22) /* write */
+# define VIP_CNTRL_2_MIRR_E   (1 << 7)
+# define VIP_CNTRL_2_SWAP_E(x)(((x) & 7) << 4)
+# define VIP_CNTRL_2_MIRR_F   (1 << 3)
+# define VIP_CNTRL_2_SWAP_F(x)(((x) & 7) << 0)
+#define REG_VIP_CNTRL_3   REG(0x00, 0x23) /* write */
+# define VIP_CNTRL_3_X_TGL(1 << 0)
+# define VIP_CNTRL_3_H_TGL(1 << 1)
+# define VIP_CNTRL_3_V_TGL(1 << 2)
+# define VIP_CNTRL_3_EMB  

[PATCH 0/4] TI LCDC DRM driver

[Rob Clark]

I think this driver is ready to go, so I've removed the 'RFC' tag.  Prove
me wrong by reviewing the patches and sending comments ;-)

The first patch adds the basic driver and TFP410 DVI output.

The second patch adds support for NXP TDA998x family of i2c connected
HDMI encoders.  It is split out into an i2c encoder-slave in case someone
else has hw with the same HDMI encoder.

The final patch adds support for LCD panels, with timings and panel info
coming from device-tree.

The patch set has dependencies on the following patches that I have sent
earlier (which have not changed since then so I am not resending):

 * drm/cma: add debugfs helpers
 * drm: i2c encoder helper wrappers

In addition, the LCD panel patch also depends on Steffen Trumtrar's OF
display helper series. I've moved this patch to last so it can be merged
later if needed.  Although I really see no reason not to merge the OF
display helper series for 3.9.

These patches and their dependencies can also be found here:

  git://people.freedesktop.org/~robclark/linux tilcdc-next
  http://cgit.freedesktop.org/~robclark/linux/log/?h=tilcdc-next

Rob Clark (4):
  drm/tilcdc: add TI LCD Controller DRM driver (v3)
  drm/i2c: nxp-tda998x (v2)
  drm/tilcdc: add encoder slave
  drm/tilcdc: add support for LCD panels (v4)

 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/i2c/Makefile   |   3 +
 drivers/gpu/drm/i2c/tda998x_drv.c  | 908 +
 drivers/gpu/drm/tilcdc/Kconfig |  25 +
 drivers/gpu/drm/tilcdc/Makefile|  10 +
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   | 597 ++
 drivers/gpu/drm/tilcdc/tilcdc_drv.c| 611 ++
 drivers/gpu/drm/tilcdc/tilcdc_drv.h| 159 ++
 drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 443 
 drivers/gpu/drm/tilcdc/tilcdc_panel.h  |  26 +
 drivers/gpu/drm/tilcdc/tilcdc_regs.h   | 154 ++
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 380 ++
 drivers/gpu/drm/tilcdc/tilcdc_slave.h  |  26 +
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 423 +++
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.h |  26 +
 16 files changed, 3794 insertions(+)
 create mode 100644 drivers/gpu/drm/i2c/tda998x_drv.c
 create mode 100644 drivers/gpu/drm/tilcdc/Kconfig
 create mode 100644 drivers/gpu/drm/tilcdc/Makefile
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_crtc.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.h
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.h
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_regs.h
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.h

-- 
1.8.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 v2 3/3] arm: omap2: gpmc: add DT bindings for OneNAND

[Tony Lindgren]

* Ezequiel Garcia  [130122 11:46]:
> On Tue, Jan 22, 2013 at 3:27 PM, Tony Lindgren  wrote:
> > * Ezequiel Garcia  [130122 10:17]:
> >> On Mon, Jan 21, 2013 at 10:32 PM, Daniel Mack  wrote:
> >> >
> >> > I'm currently far away from my computer and can't prepare a patch for 
> >> > this, sorry. But I think you are right, so please just submit a patch 
> >> > for that, anyone :-)
> >> >
> >>
> >> Ok, I'll try to submit a patch as soon as possible. If anyone wants to
> >> do it instead, fine by me.
> >
> > No please go ahead as it seems that you can easily test it too.
> >
> 
> No problem.
> 
> I now wonder if it's okey to exit upon probe failure.
> In particular, the for_each should be like this:
> 
> for_each_node_by_name(child, "nand") {
> ret = gpmc_probe_nand_child(pdev, child);
> if (ret < 0) {
> of_node_put(child);
> return ret;
> }
> }
> 
> or like this:
> 
> for_each_node_by_name(child, "nand") {
> ret = gpmc_probe_nand_child(pdev, child);
> WARN_ON(ret < 0);
> }
> 
> Ideas?

Well I would return and make sure the resources are freed.

However, if this relates to using bootloader configured values
for the few cases where we don't have the timing information
for calculations available, then just doing a warning is
the way to go.

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/3] arm: omap2: gpmc: add DT bindings for OneNAND

[Ezequiel Garcia]

On Tue, Jan 22, 2013 at 3:27 PM, Tony Lindgren  wrote:
> * Ezequiel Garcia  [130122 10:17]:
>> On Mon, Jan 21, 2013 at 10:32 PM, Daniel Mack  wrote:
>> >
>> > I'm currently far away from my computer and can't prepare a patch for 
>> > this, sorry. But I think you are right, so please just submit a patch for 
>> > that, anyone :-)
>> >
>>
>> Ok, I'll try to submit a patch as soon as possible. If anyone wants to
>> do it instead, fine by me.
>
> No please go ahead as it seems that you can easily test it too.
>

No problem.

I now wonder if it's okey to exit upon probe failure.
In particular, the for_each should be like this:

for_each_node_by_name(child, "nand") {
ret = gpmc_probe_nand_child(pdev, child);
if (ret < 0) {
of_node_put(child);
return ret;
}
}

or like this:

for_each_node_by_name(child, "nand") {
ret = gpmc_probe_nand_child(pdev, child);
WARN_ON(ret < 0);
}

Ideas?

-- 
Ezequiel
--
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] omap fixes for v3.8-rc4

[Olof Johansson]

On Tue, Jan 22, 2013 at 11:18 AM, Tony Lindgren  wrote:
> The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619:
>
>   Linux 3.8-rc4 (2013-01-17 19:25:45 -0800)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
> tags/omap-for-v3.8-rc4/fixes-signed

Pulled, thanks.


-Olof
--
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

[GIT PULL] omap fixes for v3.8-rc4

[Tony Lindgren]

The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619:

  Linux 3.8-rc4 (2013-01-17 19:25:45 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap 
tags/omap-for-v3.8-rc4/fixes-signed

for you to fetch changes up to 7662a9c60fee25d7234da4be6d8eab2b2ac88448:

  ARM: OMAP2+: omap4-panda: add UART2 muxing for WiLink shared transport 
(2013-01-21 10:39:53 -0800)


Minimal omap fixes for the -rc series:

- A build fix for recently merged omap DRM changes

- Regression fixes from the common clock framework conversion
  for omap4 audio and omap2 reboot

- Regression fix for pandaboard WLAN control UART muxing caused by
  u-boot only muxing essential pins nowadays

- Timer iteration fix for CONFIG_OF_DYNAMIC

- A section mismatch fix for ocp2scp init


Jon Hunter (1):
  ARM: OMAP2: Fix missing omap2xxx_clkt_vps_late_init function calls

Luciano Coelho (1):
  ARM: OMAP2+: omap4-panda: add UART2 muxing for WiLink shared transport

Pantelis Antoniou (1):
  ARM: OMAP2+: DT node Timer iteration fix

Peter Ujfalusi (2):
  ARM: OMAP4: clock data: Lock ABE DPLL on all revisions
  ARM: OMAP4: hwmod_data: Correct IDLEMODE for McPDM

Rob Clark (1):
  ARM: OMAP2+: fix build break for omapdrm

Tony Lindgren (2):
  Merge tag 'omap-fixes-b-for-v3.8-rc' of 
git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.8-rc4/fixes
  ARM: OMAP2+: Fix section warning for omap_init_ocp2scp()

 arch/arm/mach-omap2/board-omap4panda.c |  6 ++
 arch/arm/mach-omap2/cclock2420_data.c  |  2 ++
 arch/arm/mach-omap2/cclock2430_data.c  |  2 ++
 arch/arm/mach-omap2/cclock44xx_data.c  | 13 ++---
 arch/arm/mach-omap2/devices.c  |  2 +-
 arch/arm/mach-omap2/drm.c  |  3 ++-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  6 +-
 arch/arm/mach-omap2/timer.c|  8 ++--
 8 files changed, 26 insertions(+), 16 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 v3 00/12] video: da8xx-fb: am335x DT support

[Rob Clark]

On Tue, Jan 22, 2013 at 11:03 AM, Koen Kooi  wrote:
>
> Op 22 jan. 2013, om 17:51 heeft Afzal Mohammed  het volgende 
> geschreven:
>
>> Hi,
>>
>> This series adds DT support to da8xx-fb driver (device found on
>> DaVinci and AM335x SoC's). It does certain cleanup's in the process.
>>
>> This series as compared to previous version handles configuration of
>> the LCDC clock rate by modelling as a clock divider of CCF. This would
>> take effect only if CCF is selected, if not, no change to  existing
>> method.
>>
>> This makes use of Steffen Trumtrar's v16 of display timing DT support.
>
> Wouldn't it be better to delete da8xx-fb.* and switch to Rob Clarks DRM based 
> driver for this IP block?

we probably can't delete da8xx-fb, but I think it would be ok to only
use it for legacy platforms not yet ported to DT.

BR,
-R

> regards,
>
> Koen--
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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/10] ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data

[Tony Lindgren]

* Rajendra Nayak  [130122 05:17]:
> Hi Tony,
> 
> >>So I looked at this one with help of Rajendra. We can get rid of the
> >>IRQ and DMA data(needs DMA biding updates) easily. The address
> >>space though is needed since hwmod code uses it to setup the
> >>sysconfig registers.
> >
> >OK great. The address space tinkering in hwmod code should be
> >moved to be done in the drivers.
> >
> >As discussed earlier, there should be a driver specific reset
> >function driver_xyz_reset() in the driver header file so the
> >hwmod code can call it too in a late_initcall if no driver is
> >loaded.
> 
> I am a little confused with what you are saying. The hwmod doing
> reset of modules (and not relying on drivers doing it) was
> mainly for modules which do not have drivers built in (and hence
> run a risk of gating system sleep in case the bootloaders left
> them in a bad state).

Right, but we should not duplicate driver code in the hwmod in
those cases. And that's why those reset functions need to be in
the driver specific headers so they work both for the driver
probe, and hwmod late_initcall.

> But if the drivers aren't built in (or are built as modules) *then*
> hwmod still needs to be able to do reset (maybe in a late_initcall) of
> these modules on its own (because there is no driver code to do it).

Yes that's the idea.
 
> The other big reason why hwmod would need the address space
> tinkering is because it also controls the various OCP master/slave
> modes of these modules. Quite often these modes are broken and
> need tinkering every time the module is enable/idled and also
> need to be restored back to sane values (smart_idle/smart_standby)
> post reset. All of this is today handled as part of hwmod and
> would defeat the whole purpose of the framework if all this is
> moved into drivers.

It seems that we should have the iospace available in the driver
at that point. And it should be also available to the runtime PM
code in hwmod in the device somewhere?
 
> So completely getting rid of all address space tinkering in hwmod
> looks really difficult.

We can certainly use common hwmod functions via runtime PM for
doing that. There should not be any need to ioremap things both
in hwmod and in the driver. And there certainly should not be
need to provide duplicate iospace from both DT and hwmod. As the
DT is what we're standardizing on, we really must move over to
use that data.

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 08/10] ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data

[Tony Lindgren]

* Benoit Cousson  [130122 04:59]:
> Hi Tony,
> 
> On 01/21/2013 07:01 PM, Tony Lindgren wrote:
> > * Santosh Shilimkar  [130121 07:09]:
> >>>
> >> So I looked at this one with help of Rajendra. We can get rid of the
> >> IRQ and DMA data(needs DMA biding updates) easily. The address
> >> space though is needed since hwmod code uses it to setup the
> >> sysconfig registers.
> > 
> > OK great. The address space tinkering in hwmod code should be
> > moved to be done in the drivers.
> > 
> > As discussed earlier, there should be a driver specific reset
> > function driver_xyz_reset() in the driver header file so the
> > hwmod code can call it too in a late_initcall if no driver is
> > loaded.
> > 
> >> Extracting that from DT code seems to be really expensive and
> >> ugly [1]. I am yet to try out DMA lines removal but that seems
> >> to be doable by pulling Vinod'd DMA engine branch and updating
> >> DT file.
> > 
> > The overhead here does not matter as it should only happen in a
> > late_initcall and only for some of the drivers. For that to
> > happen we just need to go through the list of modules not yet
> > probed. We also need to have some locking in the driver specific
> > reset function to avoid races with the loadable modules.
> 
> Mmm, not really, that address is used by *every* hwmod for sysconfig
> access. So iterating over every DT nodes for every hwmods seems pretty
> ugly and un-optimized.

I think you missed one point. Iterating over all the modules should
only happen for the unused modules. With sysconfig access moved to the
drivers getting the ioaddress is done in the standard way in the driver
probe instead of iterating over all of them.
 
> That being said, it might worth checking the overhead. That will not
> make the fix nicer anyway, but at least it will allow a smooth
> transition toward a real clean solution. Assuming someone will work on
> that later, which might never happen.

Right, so who is going to do all the work needed?

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 1/2] clk: divider: prepare for minimum divider

[Stephen Boyd]

On 01/22/13 08:39, Afzal Mohammed wrote:
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index a9204c6..0b34992 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -236,7 +236,7 @@ EXPORT_SYMBOL_GPL(clk_divider_ops);
>  
>  static struct clk *_register_divider(struct device *dev, const char *name,
>   const char *parent_name, unsigned long flags,
> - void __iomem *reg, u8 shift, u8 width,
> + void __iomem *reg, u8 shift, u8 width, u8 min_div,
>   u8 clk_divider_flags, const struct clk_div_table *table,
>   spinlock_t *lock)
>  {
> @@ -261,6 +261,7 @@ static struct clk *_register_divider(struct device *dev, 
> const char *name,
>   div->reg = reg;
>   div->shift = shift;
>   div->width = width;
> + div->min_div = min_div;
>   div->flags = clk_divider_flags;
>   div->lock = lock;
>   div->hw.init = &init;
> @@ -284,16 +285,17 @@ static struct clk *_register_divider(struct device 
> *dev, const char *name,
>   * @reg: register address to adjust divider
>   * @shift: number of bits to shift the bitfield
>   * @width: width of the bitfield
> + * @min_div: minimum allowable divider value
>   * @clk_divider_flags: divider-specific flags for this clock
>   * @lock: shared register lock for this clock
>   */
>  struct clk *clk_register_divider(struct device *dev, const char *name,
>   const char *parent_name, unsigned long flags,
> - void __iomem *reg, u8 shift, u8 width,
> + void __iomem *reg, u8 shift, u8 width, u8 min_div,
>   u8 clk_divider_flags, spinlock_t *lock)
>  {
>   return _register_divider(dev, name, parent_name, flags, reg, shift,
> - width, clk_divider_flags, NULL, lock);
> + width, min_div, clk_divider_flags, NULL, lock);
>  }

Can you make a new function, clk_register_min_divider(), to avoid
disturbing all users of clock dividers that don't have a minimum? Then
the default can be put into the two registration functions in
clk-divider.c and you don't have to change all clock divider users
across the tree.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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

Re: [PATCH v2 3/3] arm: omap2: gpmc: add DT bindings for OneNAND

[Tony Lindgren]

* Ezequiel Garcia  [130122 10:17]:
> On Mon, Jan 21, 2013 at 10:32 PM, Daniel Mack  wrote:
> >
> > I'm currently far away from my computer and can't prepare a patch for this, 
> > sorry. But I think you are right, so please just submit a patch for that, 
> > anyone :-)
> >
> 
> Ok, I'll try to submit a patch as soon as possible. If anyone wants to
> do it instead, fine by me.

No please go ahead as it seems that you can easily test it too.

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] arm: omap: Fix build break in drm.c

[Tony Lindgren]

* Archit Taneja  [130122 00:32]:
> Building omapdrm leads to a build break because of a missing include needed
> for the macro GET_OMAP_REVISION(). Add the missing inlclude.

Thanks I already have a similar patch from Rob queued up.

Tony
 
> Signed-off-by: Archit Taneja 
> ---
>  arch/arm/mach-omap2/drm.c |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c
> index 4c7566c..6b1a8df 100644
> --- a/arch/arm/mach-omap2/drm.c
> +++ b/arch/arm/mach-omap2/drm.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  
> +#include "soc.h"
>  #include "omap_device.h"
>  #include "omap_hwmod.h"
>  
> -- 
> 1.7.9.5
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP baseline test results for v3.8-rc4

[Tony Lindgren]

* Mark Jackson  [130122 05:46]:
> On 22/01/13 13:32, Bedia, Vaibhav wrote:
> 
> 
> 
> > Following works for me:
> > 
> > Kernel
> > ===
> > git checkout next-20130122
> > make distclean
> > make omap2plus_defconfig
> > 
> > make -j7
> > cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb > 
> > arch/arm/boot/zImage-dtb.am335x-bone
> > mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 
> > 'Linux' -d arch/arm/boot/zImage-dtb.am335x-bone 
> > arch/arm/boot/uImage-dtb.am335x-bone
> > 
> > U-Boot
> > ===
> > Built from v2013.01
> 
> 
> 
> > A dumb question... in your case what's the bootargs set? Note that the 
> > mainline
> > kernel for AM335x doesn't have MMC support yet and the default bootargs is 
> > set to
> > rootfs on MMC.
> 
> Yes ... I'm trying to boot from a rootfs on MMC:-
> 
> Kernel command line: console=ttyO0,115200n8 earlyprintk debug 
> root=/dev/mmcblk0p2 ro rootfstype=ext2
> rootwait
> 
> But I should get *something* from the kernel before it starts trying to 
> access the rootfs ?

Here's something Kevin fixed but did not send it out before going to
a vacation. Can you give it a try with earlyprintk enabled?

Note that this does not help with no output early on, that sounds
like a bug configuring the DEBUG_LL port somewhere.

Regards,

Tony



From: Kevin Hilman 
Date: Tue, 15 Jan 2013 14:12:24 -0800
Subject: [PATCH] Fix omap_serial as module with debug_ll and earlyprintk

Otherwise we can race with the earlyconsole getting turned off
which can cause a non-booting system with earlyprintk enabled.

[t...@atomide.com: updated description]
Signed-off-by: Tony Lindgren 

---

Kevin, can I add your Signed-off-by to this one?

--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -1298,4 +1298,4 @@ static int __init omap_device_late_init(void)
bus_for_each_dev(&platform_bus_type, NULL, NULL, omap_device_late_idle);
return 0;
 }
-omap_late_initcall(omap_device_late_init);
+late_initcall_sync(omap_device_late_init);
--
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/3] arm: omap2: gpmc: add DT bindings for OneNAND

[Ezequiel Garcia]

On Mon, Jan 21, 2013 at 10:32 PM, Daniel Mack  wrote:
> Hi Tony, Mark, Ezequiel,
>
> Tony Lindgren  wrote:
>
>>* Ezequiel Garcia  [130121 09:00]:
>>> Hi Mark,
>>>
>>> On Mon, Jan 21, 2013 at 9:30 AM, Mark Rutland 
>>wrote:
>>> > [...]
>>> >
>>> >> diff --git a/arch/arm/mach-omap2/gpmc.c
>>b/arch/arm/mach-omap2/gpmc.c
>>> >> index 01ce462..f7de9eb 100644
>>> >> --- a/arch/arm/mach-omap2/gpmc.c
>>> >> +++ b/arch/arm/mach-omap2/gpmc.c
>>> >> @@ -39,6 +39,7 @@
>>> >>  #include "omap_device.h"
>>> >>  #include "gpmc.h"
>>> >>  #include "gpmc-nand.h"
>>> >> +#include "gpmc-onenand.h"
>>> >>
>>> >>  #define  DEVICE_NAME "omap-gpmc"
>>> >>
>>> >> @@ -1259,6 +1260,43 @@ static int gpmc_probe_nand_child(struct
>>platform_device *pdev,
>>> >>  }
>>> >>  #endif
>>> >>
>>> >> +#ifdef CONFIG_MTD_ONENAND
>>> >> +static int gpmc_probe_onenand_child(struct platform_device *pdev,
>>> >> +  struct device_node *child)
>>> >> +{
>>> >> + u32 val;
>>> >> + struct omap_onenand_platform_data *gpmc_onenand_data;
>>> >> +
>>> >> + if (of_property_read_u32(child, "reg", &val) < 0) {
>>> >> + dev_err(&pdev->dev, "%s has no 'reg' property\n",
>>> >> + child->full_name);
>>> >> + return -ENODEV;
>>> >> + }
>>> >> +
>>> >> + gpmc_onenand_data = devm_kzalloc(&pdev->dev,
>>sizeof(*gpmc_onenand_data),
>>> >> +  GFP_KERNEL);
>>> >> + if (!gpmc_onenand_data)
>>> >> + return -ENOMEM;
>>> >> +
>>> >> + gpmc_onenand_data->cs = val;
>>> >> + gpmc_onenand_data->of_node = child;
>>> >> + gpmc_onenand_data->dma_channel = -1;
>>> >> +
>>> >> + if (!of_property_read_u32(child, "dma-channel", &val))
>>> >> + gpmc_onenand_data->dma_channel = val;
>>> >> +
>>> >> + gpmc_onenand_init(gpmc_onenand_data);
>>> >> +
>>> >> + return 0;
>>> >> +}
>>> >> +#else
>>> >> +static int gpmc_probe_onenand_child(struct platform_device *pdev,
>>> >> + struct device_node *child)
>>> >> +{
>>> >> + return 0;
>>> >> +}
>>> >> +#endif
>>> >> +
>>> >>  static int gpmc_probe_dt(struct platform_device *pdev)
>>> >>  {
>>> >>   int ret;
>>> >> @@ -1276,6 +1314,12 @@ static int gpmc_probe_dt(struct
>>platform_device *pdev)
>>> >>   return ret;
>>> >>   }
>>> >>
>>> >
>>> > This doesn't look right to me:
>>> >
>>> >> + for_each_node_by_name(child, "onenand") {
>>> >> + ret = gpmc_probe_onenand_child(pdev, child);
>>> >> + of_node_put(child);
>>> >> + if (ret < 0)
>>> >> + return ret;
>>> >> + }
>>> >
>>> > for_each_node_by_name automatically calls of_node_put on each node
>>once passed,
>>> > and as far as I can tell, gpmc_probe_onenand_child doesn't do
>>anything that'd
>>> > increment a node's refcount.
>>> >
>>> > As far as I can see, you only need the of_node_put in the error
>>case:
>>> >
>>> > for_each_node_by_name(child, "onenand") {
>>> > ret = gpmc_probe_onenand_child(pdev, child);
>>> > if (ret < 0) {
>>> > of_node_put(child);
>>> > return ret;
>>> > }
>>> > }
>>> >
>>> > Have I missed something here?
>>> >
>>>
>>> Mmm... perhaps I've overlooked that code.
>>>
>>> After some digging through source and reading for_each_node_by_name()
>>> it seems to me you're right.
>>>
>>> @Daniel: It seems this would also apply to the NAND binding.
>>> What do you think?
>>
>>Would prefer this done as a fix against the omap-for-v3.9/gpmc
>>branch before we apply Ezequiel's patches.
>
> I'm currently far away from my computer and can't prepare a patch for this, 
> sorry. But I think you are right, so please just submit a patch for that, 
> anyone :-)
>

Ok, I'll try to submit a patch as soon as possible. If anyone wants to
do it instead, fine by me.

-- 
Ezequiel
--
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 00/12] video: da8xx-fb: am335x DT support

[Koen Kooi]

Op 22 jan. 2013, om 17:51 heeft Afzal Mohammed  het volgende 
geschreven:

> Hi,
> 
> This series adds DT support to da8xx-fb driver (device found on
> DaVinci and AM335x SoC's). It does certain cleanup's in the process.
> 
> This series as compared to previous version handles configuration of
> the LCDC clock rate by modelling as a clock divider of CCF. This would
> take effect only if CCF is selected, if not, no change to  existing
> method.
> 
> This makes use of Steffen Trumtrar's v16 of display timing DT support.

Wouldn't it be better to delete da8xx-fb.* and switch to Rob Clarks DRM based 
driver for this IP block?

regards,

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

Re: [PATCH v1 0/6] USB: Add support for multiple PHYs of same type

[Koen Kooi]

Op 22 jan. 2013, om 17:16 heeft kishon  het volgende geschreven:

> Hi,
> 
> On Tuesday 22 January 2013 09:15 PM, kishon wrote:
>> On Tuesday 22 January 2013 09:11 PM, Koen Kooi wrote:
>>> 
>>> Op 22 jan. 2013, om 10:58 heeft Kishon Vijay Abraham I 
>>> het volgende geschreven:
>>> 
 This patch series adds support for adding multiple PHY's (of same type).
 The binding information has to be present in the PHY library (otg.c) in
 order for it to return the appropriate PHY whenever the USB controller
 request for the PHY. So added a new API usb_bind_phy() to pass the
 binding
 information. This API should be called by platform specific
 initialization
 code.
 
 So the binding should be done something like
 usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto"); specifying
 the USB
 controller device name, index, and the PHY device name.
 I have done this binding for OMAP platforms, but it should be done for
 all the platforms.
 
 After this design, the phy can be got by passing the USB controller
 device
 pointer and the index.
 
 Developed this patch series on
 git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv
 after applying "usb: musb: add driver for control module" patch series
 and "ARM: dts: omap: add dt data for MUSB"
 
 Did basic enumeration testing in omap4 panda and omap3 beagle.
>>> 
>>> With this patchset USB completely breaks on am33xx beaglebone, is that
>>> intended?
>> Not really.
>> Does am33xx makes use of omap2430.c? Which PHY does am33xx uses?
> 
> I figured out it uses drivers/usb/musb/musb_dsps.c (So it doesn't use 
> omap2430.c). I think it uses TWL4030_USB (TPS659x0) as PHY.

Actually it uses nop-phy as a phy, which is missing from 
arch/arm/boot/dts/am33xx.dtsi, so mainline is already broken. But adding the 
nop-phy to the DT is easy enough to patch in locally.

regards,

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

[PATCH v3 03/12] video: da8xx-fb: enable sync lost intr for v2 ip

[Afzal Mohammed]

interrupt handler is checking for sync lost interrupt, but it was not
enabled, enable it.

Signed-off-by: Afzal Mohammed 
---
 drivers/video/da8xx-fb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 7f92f37..ca69e01 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -318,7 +318,7 @@ static void lcd_blit(int load_mode, struct da8xx_fb_par 
*par)
reg_int = lcdc_read(LCD_INT_ENABLE_SET_REG) |
LCD_V2_END_OF_FRAME0_INT_ENA |
LCD_V2_END_OF_FRAME1_INT_ENA |
-   LCD_FRAME_DONE;
+   LCD_FRAME_DONE | LCD_SYNC_LOST;
lcdc_write(reg_int, LCD_INT_ENABLE_SET_REG);
}
reg_dma |= LCD_DUAL_FRAME_BUFFER_ENABLE;
-- 
1.7.12

--
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 05/12] video: da8xx-fb: ensure non-null cfg in pdata

[Afzal Mohammed]

Ensure that platform data contains pointer for lcd_ctrl_config.

Signed-off-by: Afzal Mohammed 
---
 drivers/video/da8xx-fb.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 7a32e83..3b146bc 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1320,6 +1320,11 @@ static int fb_probe(struct platform_device *device)
 
lcd_cfg = (struct lcd_ctrl_config *)fb_pdata->controller_data;
 
+   if (!lcd_cfg) {
+   ret = -EINVAL;
+   goto err_pm_runtime_disable;
+   }
+
da8xx_fb_info = framebuffer_alloc(sizeof(struct da8xx_fb_par),
&device->dev);
if (!da8xx_fb_info) {
-- 
1.7.12

--
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 04/12] video: da8xx-fb: use devres

[Afzal Mohammed]

Replace existing resource handling in the driver with managed device
resource.

Signed-off-by: Afzal Mohammed 
---
 drivers/video/da8xx-fb.c | 35 ++-
 1 file changed, 6 insertions(+), 29 deletions(-)

diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index ca69e01..7a32e83 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1036,12 +1036,9 @@ static int fb_remove(struct platform_device *dev)
  par->p_palette_base);
dma_free_coherent(NULL, par->vram_size, par->vram_virt,
  par->vram_phys);
-   free_irq(par->irq, par);
pm_runtime_put_sync(&dev->dev);
pm_runtime_disable(&dev->dev);
framebuffer_release(info);
-   iounmap(da8xx_fb_reg_base);
-   release_mem_region(lcdc_regs->start, resource_size(lcdc_regs));
 
}
return 0;
@@ -1265,7 +1262,6 @@ static int fb_probe(struct platform_device *device)
struct fb_info *da8xx_fb_info;
struct clk *fb_clk = NULL;
struct da8xx_fb_par *par;
-   resource_size_t len;
int ret, i;
unsigned long ulcm;
 
@@ -1275,29 +1271,16 @@ static int fb_probe(struct platform_device *device)
}
 
lcdc_regs = platform_get_resource(device, IORESOURCE_MEM, 0);
-   if (!lcdc_regs) {
-   dev_err(&device->dev,
-   "Can not get memory resource for LCD controller\n");
-   return -ENOENT;
-   }
-
-   len = resource_size(lcdc_regs);
-
-   lcdc_regs = request_mem_region(lcdc_regs->start, len, lcdc_regs->name);
-   if (!lcdc_regs)
-   return -EBUSY;
-
-   da8xx_fb_reg_base = ioremap(lcdc_regs->start, len);
+   da8xx_fb_reg_base = devm_request_and_ioremap(&device->dev, lcdc_regs);
if (!da8xx_fb_reg_base) {
-   ret = -EBUSY;
-   goto err_request_mem;
+   dev_err(&device->dev, "memory resource setup failed\n");
+   return -EADDRNOTAVAIL;
}
 
-   fb_clk = clk_get(&device->dev, "fck");
+   fb_clk = devm_clk_get(&device->dev, "fck");
if (IS_ERR(fb_clk)) {
dev_err(&device->dev, "Can not get device clock\n");
-   ret = -ENODEV;
-   goto err_ioremap;
+   return -ENODEV;
}
 
pm_runtime_enable(&device->dev);
@@ -1458,7 +1441,7 @@ static int fb_probe(struct platform_device *device)
lcdc_irq_handler = lcdc_irq_handler_rev02;
}
 
-   ret = request_irq(par->irq, lcdc_irq_handler, 0,
+   ret = devm_request_irq(&device->dev, par->irq, lcdc_irq_handler, 0,
DRIVER_NAME, par);
if (ret)
goto irq_freq;
@@ -1488,12 +1471,6 @@ err_pm_runtime_disable:
pm_runtime_put_sync(&device->dev);
pm_runtime_disable(&device->dev);
 
-err_ioremap:
-   iounmap(da8xx_fb_reg_base);
-
-err_request_mem:
-   release_mem_region(lcdc_regs->start, len);
-
return ret;
 }
 
-- 
1.7.12

--
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 07/12] video: da8xx-fb: minimal dt support

[Afzal Mohammed]

Driver is provided a means to have the probe triggered by DT.

Signed-off-by: Afzal Mohammed 
---
 Documentation/devicetree/bindings/video/fb-da8xx.txt | 16 
 drivers/video/da8xx-fb.c |  7 +++
 2 files changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/fb-da8xx.txt

diff --git a/Documentation/devicetree/bindings/video/fb-da8xx.txt 
b/Documentation/devicetree/bindings/video/fb-da8xx.txt
new file mode 100644
index 000..581e014
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/fb-da8xx.txt
@@ -0,0 +1,16 @@
+TI LCD Controller on DA830/DA850/AM335x SoC's
+
+Required properties:
+- compatible:
+   DA830 - "ti,da830-lcdc"
+   AM335x SoC's - "ti,am3352-lcdc", "ti,da830-lcdc"
+- reg: Address range of lcdc register set
+- interrupts: lcdc interrupt
+
+Example:
+
+lcdc@4830e000 {
+   compatible = "ti,am3352-lcdc", "ti,da830-lcdc";
+   reg =  <0x4830e000 0x1000>;
+   interrupts = <36>;
+};
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index b6ea5e9..08ee8eb 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1595,6 +1595,12 @@ static int fb_resume(struct platform_device *dev)
 #define fb_resume NULL
 #endif
 
+static const struct of_device_id da8xx_fb_of_match[] = {
+   {.compatible = "ti,da830-lcdc", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, da8xx_fb_of_match);
+
 static struct platform_driver da8xx_fb_driver = {
.probe = fb_probe,
.remove = fb_remove,
@@ -1603,6 +1609,7 @@ static struct platform_driver da8xx_fb_driver = {
.driver = {
   .name = DRIVER_NAME,
   .owner = THIS_MODULE,
+  .of_match_table = of_match_ptr(da8xx_fb_of_match),
   },
 };
 
-- 
1.7.12

--
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 01/12] video: da8xx-fb: make io operations safe

[Afzal Mohammed]

Replace __raw_readl/__raw_writel with readl/writel; this driver is
reused on ARMv7 (AM335x SoC).

Signed-off-by: Afzal Mohammed 
---

v2: new patch

 drivers/video/da8xx-fb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 720604c..35a33ca 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -141,12 +141,12 @@ static int frame_done_flag;
 
 static inline unsigned int lcdc_read(unsigned int addr)
 {
-   return (unsigned int)__raw_readl(da8xx_fb_reg_base + (addr));
+   return (unsigned int)readl(da8xx_fb_reg_base + (addr));
 }
 
 static inline void lcdc_write(unsigned int val, unsigned int addr)
 {
-   __raw_writel(val, da8xx_fb_reg_base + (addr));
+   writel(val, da8xx_fb_reg_base + (addr));
 }
 
 struct da8xx_fb_par {
-- 
1.7.12

--
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 02/12] video: da8xx-fb: fix 24bpp raster configuration

[Afzal Mohammed]

From: "Manjunathappa, Prakash" 

Set only LCD_V2_TFT_24BPP_MODE bit for 24bpp and LCD_V2_TFT_24BPP_UNPACK
bit along with LCD_V2_TFT_24BPP_MODE for 32bpp configuration.

Patch is tested on am335x-evm for 24bpp and da850-evm for 16bpp
configurations.

Signed-off-by: Manjunathappa, Prakash 
Signed-off-by: Afzal Mohammed 
---
 drivers/video/da8xx-fb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 35a33ca..7f92f37 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -550,10 +550,10 @@ static int lcd_cfg_frame_buffer(struct da8xx_fb_par *par, 
u32 width, u32 height,
case 4:
case 16:
break;
-   case 24:
-   reg |= LCD_V2_TFT_24BPP_MODE;
case 32:
reg |= LCD_V2_TFT_24BPP_UNPACK;
+   case 24:
+   reg |= LCD_V2_TFT_24BPP_MODE;
break;
 
case 8:
-- 
1.7.12

--
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 09/12] video: da8xx-fb: obtain fb_videomode info from dt

[Afzal Mohammed]

Obtain fb_videomode details for the connected lcd panel using the
display timing details present in DT.

Signed-off-by: Afzal Mohammed 
---
 .../devicetree/bindings/video/fb-da8xx.txt  | 21 +
 drivers/video/da8xx-fb.c| 17 +
 2 files changed, 38 insertions(+)

diff --git a/Documentation/devicetree/bindings/video/fb-da8xx.txt 
b/Documentation/devicetree/bindings/video/fb-da8xx.txt
index 581e014..0741f78 100644
--- a/Documentation/devicetree/bindings/video/fb-da8xx.txt
+++ b/Documentation/devicetree/bindings/video/fb-da8xx.txt
@@ -6,6 +6,12 @@ Required properties:
AM335x SoC's - "ti,am3352-lcdc", "ti,da830-lcdc"
 - reg: Address range of lcdc register set
 - interrupts: lcdc interrupt
+- display-timings: typical videomode of lcd panel, represented as child.
+  Refer Documentation/devicetree/bindings/video/display-timing.txt for
+  display timing binding details. If multiple videomodes are mentioned
+  in display timings node, typical videomode has to be mentioned as the
+  native mode or it has to be first child (driver cares only for native
+  videomode).
 
 Example:
 
@@ -13,4 +19,19 @@ lcdc@4830e000 {
compatible = "ti,am3352-lcdc", "ti,da830-lcdc";
reg =  <0x4830e000 0x1000>;
interrupts = <36>;
+   display-timings {
+   800x480p62 {
+   clock-frequency = <3000>;
+   hactive = <800>;
+   vactive = <480>;
+   hfront-porch = <39>;
+   hback-porch = <39>;
+   hsync-len = <47>;
+   vback-porch = <29>;
+   vfront-porch = <13>;
+   vsync-len = <2>;
+   hsync-active = <1>;
+   vsync-active = <1>;
+   };
+   };
 };
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 0beed20..0c68712 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -1257,8 +1258,24 @@ static struct fb_videomode 
*da8xx_fb_get_videomode(struct platform_device *dev)
 {
struct da8xx_lcdc_platform_data *fb_pdata = dev->dev.platform_data;
struct fb_videomode *lcdc_info;
+   struct device_node *np = dev->dev.of_node;
int i;
 
+   if (np) {
+   lcdc_info = devm_kzalloc(&dev->dev,
+sizeof(struct fb_videomode),
+GFP_KERNEL);
+   if (!lcdc_info) {
+   dev_err(&dev->dev, "memory allocation failed\n");
+   return NULL;
+   }
+   if (of_get_fb_videomode(np, lcdc_info, OF_USE_NATIVE_MODE)) {
+   dev_err(&dev->dev, "timings not available in DT\n");
+   return NULL;
+   }
+   return lcdc_info;
+   }
+
for (i = 0, lcdc_info = known_lcd_panels;
i < ARRAY_SIZE(known_lcd_panels); i++, lcdc_info++) {
if (strcmp(fb_pdata->type, lcdc_info->name) == 0)
-- 
1.7.12

--
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 10/12] video: da8xx-fb: ensure pdata only for non-dt

[Afzal Mohammed]

This driver is DT probe-able, hence ensure presence of platform data
only for non-DT boot.

Signed-off-by: Afzal Mohammed 
---
 drivers/video/da8xx-fb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 0c68712..1c1a616 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1303,7 +1303,7 @@ static int fb_probe(struct platform_device *device)
int ret;
unsigned long ulcm;
 
-   if (fb_pdata == NULL) {
+   if (fb_pdata == NULL && !device->dev.of_node) {
dev_err(&device->dev, "Can not get platform data\n");
return -ENOENT;
}
-- 
1.7.12

--
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 11/12] video: da8xx-fb: setup struct lcd_ctrl_config for dt

[Afzal Mohammed]

strcut lcd_ctrl_config information required for driver is currently
obtained via platform data. To handle DT probing, create
lcd_ctrl_config and populate it with default values, these values are
sufficient for the panels so far used with this controller to work.

Signed-off-by: Afzal Mohammed 
---
 drivers/video/da8xx-fb.c | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 1c1a616..5455682 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1254,6 +1254,35 @@ static struct fb_ops da8xx_fb_ops = {
.fb_blank = cfb_blank,
 };
 
+static struct lcd_ctrl_config *da8xx_fb_create_cfg(struct platform_device *dev)
+{
+   struct lcd_ctrl_config *cfg;
+
+   cfg = devm_kzalloc(&dev->dev, sizeof(struct fb_videomode), GFP_KERNEL);
+   if (!cfg) {
+   dev_err(&dev->dev, "memory allocation failed\n");
+   return NULL;
+   }
+
+   /* default values */
+
+   if (lcd_revision == LCD_VERSION_1)
+   cfg->bpp = 16;
+   else
+   cfg->bpp = 32;
+
+   /*
+* For panels so far used with this LCDC, below statement is sufficient.
+* For new panels, if required, struct lcd_ctrl_cfg fields to be updated
+* with additional/modified values. Those values would have to be then
+* obtained from dt(requiring new dt bindings).
+*/
+
+   cfg->panel_shade = COLOR_ACTIVE;
+
+   return cfg;
+}
+
 static struct fb_videomode *da8xx_fb_get_videomode(struct platform_device *dev)
 {
struct da8xx_lcdc_platform_data *fb_pdata = dev->dev.platform_data;
@@ -1345,7 +1374,10 @@ static int fb_probe(struct platform_device *device)
break;
}
 
-   lcd_cfg = (struct lcd_ctrl_config *)fb_pdata->controller_data;
+   if (device->dev.of_node)
+   lcd_cfg = da8xx_fb_create_cfg(device);
+   else
+   lcd_cfg = (struct lcd_ctrl_config *)fb_pdata->controller_data;
 
if (!lcd_cfg) {
ret = -EINVAL;
-- 
1.7.12

--
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 12/12] video: da8xx-fb: CCF clock divider handling

[Afzal Mohammed]

Common clock framework provides a basic clock divider. Make use of it
to handle clock configuration in the LCDC IP, wherever applicable;
out of two platforms having this IP, only am335x is converted to use
CCF, DaVinci is not yet converted. Hence wrap the modification such
that it will come into effect only if CCF is selected, otherwise,
prgram dividers as earlier. Once DaVinci is converted to use CCF,
this ifdef'ery can be removed.

Divider clock instantiated is made as a one that allows the rate
propogation to it's parent, that provides more options w.r.t pixel
clock rates that could be configured.

Signed-off-by: Afzal Mohammed 
---

v3: model CCF clock divider with parent propogation if CCF selected
v2: new patch

 drivers/video/da8xx-fb.c | 67 ++--
 1 file changed, 65 insertions(+), 2 deletions(-)

diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 5455682..3c9db1d 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -133,6 +134,10 @@
 #define WSI_TIMEOUT50
 #define PALETTE_SIZE   256
 
+#defineLCD_CLK_SHIFT   8
+#defineLCD_CLK_WIDTH   8
+#defineLCD_CLK_MIN_DIV 2
+
 static void __iomem *da8xx_fb_reg_base;
 static struct resource *lcdc_regs;
 static unsigned int lcd_revision;
@@ -181,6 +186,9 @@ struct da8xx_fb_par {
u32 pseudo_palette[16];
struct fb_videomode mode;
struct lcd_ctrl_config  cfg;
+#ifdef CONFIG_COMMON_CLK
+   struct clk  *child_clk;
+#endif
 };
 
 static struct fb_var_screeninfo da8xx_fb_var;
@@ -689,6 +697,19 @@ static inline unsigned da8xx_fb_calc_clk_divider(struct 
da8xx_fb_par *par,
return par->lcd_fck_rate / (PICOS2KHZ(pixclock) * 1000);
 }
 
+#ifdef CONFIG_COMMON_CLK
+static inline unsigned da8xx_fb_round_clk(struct da8xx_fb_par *par,
+ unsigned pixclock)
+{
+   unsigned long rate;
+
+   rate = PICOS2KHZ(pixclock) * 1000;
+   rate = clk_round_rate(par->child_clk, rate);
+   rate = KHZ2PICOS(rate / 1000);
+
+   return rate;
+}
+#else
 static inline unsigned da8xx_fb_round_clk(struct da8xx_fb_par *par,
  unsigned pixclock)
 {
@@ -697,25 +718,49 @@ static inline unsigned da8xx_fb_round_clk(struct 
da8xx_fb_par *par,
div = da8xx_fb_calc_clk_divider(par, pixclock);
return KHZ2PICOS(par->lcd_fck_rate / (1000 * div));
 }
+#endif
 
 static inline void da8xx_fb_config_clk_divider(unsigned div)
 {
/* Configure the LCD clock divisor. */
lcdc_write(LCD_CLK_DIVISOR(div) |
(LCD_RASTER_MODE & 0x1), LCD_CTRL_REG);
+}
 
+static inline void da8xx_fb_clkc_enable(void)
+{
if (lcd_revision == LCD_VERSION_2)
lcdc_write(LCD_V2_DMA_CLK_EN | LCD_V2_LIDD_CLK_EN |
LCD_V2_CORE_CLK_EN, LCD_CLK_ENABLE_REG);
 }
 
-static inline void da8xx_fb_calc_config_clk_divider(struct da8xx_fb_par *par,
+#ifdef CONFIG_COMMON_CLK
+static inline int da8xx_fb_calc_config_clk_divider(struct da8xx_fb_par *par,
+   struct fb_videomode *mode)
+{
+   int ret;
+
+   ret = clk_set_rate(par->child_clk, PICOS2KHZ(mode->pixclock) * 1000);
+   if (IS_ERR_VALUE(ret)) {
+   dev_err(par->dev, "unable to setup pixel clock of %u ps",
+   mode->pixclock);
+   return ret;
+   }
+   da8xx_fb_clkc_enable();
+   return 0;
+}
+#else
+static inline int da8xx_fb_calc_config_clk_divider(struct da8xx_fb_par *par,
struct fb_videomode *mode)
 {
unsigned div = da8xx_fb_calc_clk_divider(par, mode->pixclock);
 
da8xx_fb_config_clk_divider(div);
+   da8xx_fb_clkc_enable();
+
+   return 0;
 }
+#endif
 
 static int lcd_init(struct da8xx_fb_par *par, const struct lcd_ctrl_config 
*cfg,
struct fb_videomode *panel)
@@ -723,7 +768,9 @@ static int lcd_init(struct da8xx_fb_par *par, const struct 
lcd_ctrl_config *cfg,
u32 bpp;
int ret = 0;
 
-   da8xx_fb_calc_config_clk_divider(par, panel);
+   ret = da8xx_fb_calc_config_clk_divider(par, panel);
+   if (IS_ERR_VALUE(ret))
+   return ret;
 
if (panel->sync & FB_SYNC_CLK_INVERT)
lcdc_write((lcdc_read(LCD_RASTER_TIMING_2_REG) |
@@ -1406,6 +1453,22 @@ static int fb_probe(struct platform_device *device)
 
da8xx_fb_lcd_reset();
 
+#ifdef CONFIG_COMMON_CLK
+   lcdc_write(LCD_RASTER_MODE | LCD_CLK_DIVISOR(0x2), LCD_CTRL_REG);
+   par->child_clk = clk_register_divider(NULL, "da8xx_fb_clk",
+ __clk_get_name(fb_clk),
+ CLK_SET_RATE_PARENT,
+ da8xx_fb_reg

[PATCH v3 08/12] video: da8xx-fb: invoke platform callback safely

[Afzal Mohammed]

Ensure that platform data is present before checking whether platform
callback is present (the one used to control backlight). So far this
was not an issue as driver was purely non-DT triggered, but now DT
support has been added.

Signed-off-by: Afzal Mohammed 
---
 drivers/video/da8xx-fb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 08ee8eb..0beed20 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1347,7 +1347,7 @@ static int fb_probe(struct platform_device *device)
par->dev = &device->dev;
par->lcdc_clk = fb_clk;
par->lcd_fck_rate = clk_get_rate(fb_clk);
-   if (fb_pdata->panel_power_ctrl) {
+   if (fb_pdata && fb_pdata->panel_power_ctrl) {
par->panel_power_ctrl = fb_pdata->panel_power_ctrl;
par->panel_power_ctrl(1);
}
-- 
1.7.12

--
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 06/12] video: da8xx-fb: reorganize panel detection

[Afzal Mohammed]

Move panel detection to a separate function, this helps in readability
as well as makes DT support cleaner.

Signed-off-by: Afzal Mohammed 
---
 drivers/video/da8xx-fb.c | 42 ++
 1 file changed, 26 insertions(+), 16 deletions(-)

diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 3b146bc..b6ea5e9 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -1253,6 +1253,27 @@ static struct fb_ops da8xx_fb_ops = {
.fb_blank = cfb_blank,
 };
 
+static struct fb_videomode *da8xx_fb_get_videomode(struct platform_device *dev)
+{
+   struct da8xx_lcdc_platform_data *fb_pdata = dev->dev.platform_data;
+   struct fb_videomode *lcdc_info;
+   int i;
+
+   for (i = 0, lcdc_info = known_lcd_panels;
+   i < ARRAY_SIZE(known_lcd_panels); i++, lcdc_info++) {
+   if (strcmp(fb_pdata->type, lcdc_info->name) == 0)
+   break;
+   }
+
+   if (i == ARRAY_SIZE(known_lcd_panels)) {
+   dev_err(&dev->dev, "no panel found\n");
+   return NULL;
+   }
+   dev_info(&dev->dev, "found %s panel\n", lcdc_info->name);
+
+   return lcdc_info;
+}
+
 static int fb_probe(struct platform_device *device)
 {
struct da8xx_lcdc_platform_data *fb_pdata =
@@ -1262,7 +1283,7 @@ static int fb_probe(struct platform_device *device)
struct fb_info *da8xx_fb_info;
struct clk *fb_clk = NULL;
struct da8xx_fb_par *par;
-   int ret, i;
+   int ret;
unsigned long ulcm;
 
if (fb_pdata == NULL) {
@@ -1270,6 +1291,10 @@ static int fb_probe(struct platform_device *device)
return -ENOENT;
}
 
+   lcdc_info = da8xx_fb_get_videomode(device);
+   if (lcdc_info == NULL)
+   return -ENODEV;
+
lcdc_regs = platform_get_resource(device, IORESOURCE_MEM, 0);
da8xx_fb_reg_base = devm_request_and_ioremap(&device->dev, lcdc_regs);
if (!da8xx_fb_reg_base) {
@@ -1303,21 +1328,6 @@ static int fb_probe(struct platform_device *device)
break;
}
 
-   for (i = 0, lcdc_info = known_lcd_panels;
-   i < ARRAY_SIZE(known_lcd_panels);
-   i++, lcdc_info++) {
-   if (strcmp(fb_pdata->type, lcdc_info->name) == 0)
-   break;
-   }
-
-   if (i == ARRAY_SIZE(known_lcd_panels)) {
-   dev_err(&device->dev, "GLCD: No valid panel found\n");
-   ret = -ENODEV;
-   goto err_pm_runtime_disable;
-   } else
-   dev_info(&device->dev, "GLCD: Found %s panel\n",
-   fb_pdata->type);
-
lcd_cfg = (struct lcd_ctrl_config *)fb_pdata->controller_data;
 
if (!lcd_cfg) {
-- 
1.7.12

--
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 00/12] video: da8xx-fb: am335x DT support

[Afzal Mohammed]

Hi,

This series adds DT support to da8xx-fb driver (device found on
DaVinci and AM335x SoC's). It does certain cleanup's in the process.

This series as compared to previous version handles configuration of
the LCDC clock rate by modelling as a clock divider of CCF. This would
take effect only if CCF is selected, if not, no change to  existing
method.

This makes use of Steffen Trumtrar's v16 of display timing DT support.

Testing has been done on AM335x SoC based boards like AM335x EVM. It
has also been verified that display on DA850 EVM (non-DT boot) works
as earlier.

This series is based on v3.8-rc3,
 and is dependent on,
1. Series v16 "of: add display helper" by,
Steffen Trumtrar 
2. Patch "da8xx: Allow use by am33xx based devices" by,
Pantelis Antoniou 
3. Series v3 "video: da8xx-fb: runtime timing configuration" by,
me (Afzal Mohammed )

To test this series on AM335x based boards,
1. Series v2 "ARM: dts: AM33XX: lcdc support" by,
me (Afzal Mohammed ),
2. Series "HWMOD fixes for AM33xx PWM submodules and device tree nodes" by,
Philip, Avinash 
3. Series "clk: divider: prepare for minimum divider" by,
me (Afzal Mohammed ),
4. Series "ARM: AM335x: LCDC platform support" by,
me (Afzal Mohammed ),
would be needed.

All above dependencies along with those required for testing is available
@ git://gitorious.org/x0148406-public/linux-kernel.git tags/da8xx-fb-dt-v3

Regards
Afzal

v3: model CCF clock divider with parent propogation if CCF selected
v2: 2 new patches - one to configure clock rate properly (12/12)and
other to make io operations safe (1/12)

Afzal Mohammed (11):
  video: da8xx-fb: make io operations safe
  video: da8xx-fb: enable sync lost intr for v2 ip
  video: da8xx-fb: use devres
  video: da8xx-fb: ensure non-null cfg in pdata
  video: da8xx-fb: reorganize panel detection
  video: da8xx-fb: minimal dt support
  video: da8xx-fb: invoke platform callback safely
  video: da8xx-fb: obtain fb_videomode info from dt
  video: da8xx-fb: ensure pdata only for non-dt
  video: da8xx-fb: setup struct lcd_ctrl_config for dt
  video: da8xx-fb: CCF clock divider handling

Manjunathappa, Prakash (1):
  video: da8xx-fb: fix 24bpp raster configuration

 .../devicetree/bindings/video/fb-da8xx.txt |  37 
 drivers/video/da8xx-fb.c   | 217 -
 2 files changed, 201 insertions(+), 53 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/video/fb-da8xx.txt

-- 
1.7.12

--
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 3/4] ARM: OMAP2+: clock: DEFINE_STRUCT_CLK_FLAGS helper

[Afzal Mohammed]

DEFINE_STRUCT_CLK does not have the capability to set flags, define
DEFINE_STRUCT_CLK_FLAGS to handle flags. This is needed to add
SET_RATE_PARENT flag in statically defined lcd clock in am335x.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/clock.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index b402048..60ddd86 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -65,6 +65,17 @@ struct clockdomain;
.ops = &_clkops_name,   \
};
 
+#define DEFINE_STRUCT_CLK_FLAGS(_name, _parent_array_name, \
+   _clkops_name, _flags)   \
+   static struct clk _name = { \
+   .name = #_name, \
+   .hw = &_name##_hw.hw,   \
+   .parent_names = _parent_array_name, \
+   .num_parents = ARRAY_SIZE(_parent_array_name),  \
+   .ops = &_clkops_name,   \
+   .flags = _flags,\
+   };
+
 #define DEFINE_STRUCT_CLK_HW_OMAP(_name, _clkdm_name)  \
static struct clk_hw_omap _name##_hw = {\
.hw = { \
-- 
1.7.12

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

[PATCH 1/4] ARM: OMAP2+: dpll: round rate to closest value

[Afzal Mohammed]

Currently round rate function would return proper rate iff requested
rate exactly matches the PLL lockable rate. This causes set_rate to
fail if exact rate could not be set. Instead round rate may return
closest rate possible (less than the requested). And if any user is
badly in need of exact rate, then return value of round rate could
be used to decide whether to invoke set rate or not.

Modify round rate so that it return closest possible rate.

This was required to get display working on am335x. Without this
display rate could not be set (taking help of SET_RATE_PARENT). Couple
of the downstream clocks of display PLL are basic clock dividers and
they do MULT_ROUND_UP before requesting rate on PLL causing values
that mostly could not be locked by PLL. And even otherwise, if
requested rate for a particular pixel clock could not be satisfied by
PLL, display would not work. This change will resolve the issue.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/clkt_dpll.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/clkt_dpll.c b/arch/arm/mach-omap2/clkt_dpll.c
index 924c230..15e6d41 100644
--- a/arch/arm/mach-omap2/clkt_dpll.c
+++ b/arch/arm/mach-omap2/clkt_dpll.c
@@ -345,20 +345,22 @@ long omap2_dpll_round_rate(struct clk_hw *hw, unsigned 
long target_rate,
pr_debug("clock: %s: m = %d: n = %d: new_rate = %ld\n",
 clk_name, m, n, new_rate);
 
-   if (target_rate == new_rate) {
+   if ((new_rate <= target_rate) &&
+   (new_rate > dd->last_rounded_rate)) {
dd->last_rounded_m = m;
dd->last_rounded_n = n;
-   dd->last_rounded_rate = target_rate;
-   break;
+   dd->last_rounded_rate = new_rate;
+   if (new_rate == target_rate)
+   break;
}
}
 
-   if (target_rate != new_rate) {
+   if (!dd->last_rounded_rate) {
pr_debug("clock: %s: cannot round to rate %ld\n",
 clk_name, target_rate);
return ~0;
}
 
-   return target_rate;
+   return dd->last_rounded_rate;
 }
 
-- 
1.7.12

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

[PATCH 4/4] ARM: AM33XX: clock: SET_RATE_PARENT in lcd path

[Afzal Mohammed]

LCDC clock node is a one that does not have set rate capability. It
just passes on the rate that is sent downstream by it's parent. While
lcdc clock parent and it's grand parent - dpll_disp_m2_ck and
dpll_disp_ck has the capability to configure rate.

And the default rates provided by LCDC clock's ancestors are not
sufficient to obtain pixel clock for current LCDC use cases, hence
currently display would not work on AM335x SoC's (with driver
modifications in platfrom independent way).

Hence inform clock framework to propogate set rate for LCDC clock as
well as it's parent - dpll_disp_m2_ck. With this change, set rate on
LCDC clock would get propogated till dpll_disp_ck via dpll_disp_m2_ck,
hence allowing the driver (same driver is used in DaVinci too) to set
rates using LCDC clock without worrying about platform dependent clock
details.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/cclock33xx_data.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/cclock33xx_data.c 
b/arch/arm/mach-omap2/cclock33xx_data.c
index 8f7c60d..0519e91 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -286,10 +286,10 @@ DEFINE_STRUCT_CLK(dpll_disp_ck, dpll_core_ck_parents, 
dpll_ddr_ck_ops);
  * TODO: Add clksel here (sys_clkin, CORE_CLKOUTM6, PER_CLKOUTM2
  * and ALT_CLK1/2)
  */
-DEFINE_CLK_DIVIDER(dpll_disp_m2_ck, "dpll_disp_ck", &dpll_disp_ck, 0x0,
-  AM33XX_CM_DIV_M2_DPLL_DISP, AM33XX_DPLL_CLKOUT_DIV_SHIFT,
-  AM33XX_DPLL_CLKOUT_DIV_WIDTH, CLK_DIVIDER_MIN_DIV_DEFAULT,
-  CLK_DIVIDER_ONE_BASED, NULL);
+DEFINE_CLK_DIVIDER(dpll_disp_m2_ck, "dpll_disp_ck", &dpll_disp_ck,
+  CLK_SET_RATE_PARENT, AM33XX_CM_DIV_M2_DPLL_DISP,
+  AM33XX_DPLL_CLKOUT_DIV_SHIFT, AM33XX_DPLL_CLKOUT_DIV_WIDTH,
+  CLK_DIVIDER_MIN_DIV_DEFAULT, CLK_DIVIDER_ONE_BASED, NULL);
 
 /* DPLL_PER */
 static struct dpll_data dpll_per_dd = {
@@ -726,7 +726,8 @@ static struct clk_hw_omap lcd_gclk_hw = {
.clksel_mask= AM33XX_CLKSEL_0_1_MASK,
 };
 
-DEFINE_STRUCT_CLK(lcd_gclk, lcd_ck_parents, gpio_fck_ops);
+DEFINE_STRUCT_CLK_FLAGS(lcd_gclk, lcd_ck_parents,
+   gpio_fck_ops, CLK_SET_RATE_PARENT);
 
 DEFINE_CLK_FIXED_FACTOR(mmc_clk, "dpll_per_m2_ck", &dpll_per_m2_ck, 0x0, 1, 2);
 
-- 
1.7.12

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

[PATCH 2/4] ARM: OMAP2+: dpll: am335x - avoid freqsel

[Afzal Mohammed]

am335x does not have freqsel, avoid it.

Signed-off-by: Afzal Mohammed 
---
 arch/arm/mach-omap2/dpll3xxx.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 0a02aab5..3aed4b0 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -500,8 +500,9 @@ int omap3_noncore_dpll_set_rate(struct clk_hw *hw, unsigned 
long rate,
if (dd->last_rounded_rate == 0)
return -EINVAL;
 
-   /* No freqsel on OMAP4 and OMAP3630 */
-   if (!cpu_is_omap44xx() && !cpu_is_omap3630()) {
+   /* No freqsel on AM335x, OMAP4 and OMAP3630 */
+   if (!soc_is_am33xx() && !cpu_is_omap44xx() &&
+   !cpu_is_omap3630()) {
freqsel = _omap3_dpll_compute_freqsel(clk,
dd->last_rounded_n);
WARN_ON(!freqsel);
-- 
1.7.12

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

[PATCH 0/4] ARM: AM335x: LCDC platform support

[Afzal Mohammed]

Hi,

This series make am335x lcdc capable of providing display.
Certain changes were required in generic OMAP clock handling
to attain it. Clock nodes in LCDC path is marked such that
rate can get propogated to upstream clocks till display PLL.

Based on 3.8-rc3.

Tested on AM335x EVM.

To test on AM335x based boards, tree
@ git://gitorious.org/x0148406-public/linux-kernel.git tags/da8xx-fb-dt-v3

Regards
Afzal

Afzal Mohammed (4):
  ARM: OMAP2+: dpll: round rate to closest value
  ARM: OMAP2+: dpll: am335x - avoid freqsel
  ARM: OMAP2+: clock: DEFINE_STRUCT_CLK_FLAGS helper
  ARM: AM33XX: clock: SET_RATE_PARENT in lcd path

 arch/arm/mach-omap2/cclock33xx_data.c | 11 ++-
 arch/arm/mach-omap2/clkt_dpll.c   | 12 +++-
 arch/arm/mach-omap2/clock.h   | 11 +++
 arch/arm/mach-omap2/dpll3xxx.c|  5 +++--
 4 files changed, 27 insertions(+), 12 deletions(-)

-- 
1.7.12

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

[PATCH 2/2] clk: divider: handle minimum divider

[Afzal Mohammed]

Some of clocks can have a limit on minimum divider value that can be
programmed. Modify basic clock divider to take care of this aspect.

Signed-off-by: Afzal Mohammed 
---
 drivers/clk/clk-divider.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 0b34992..2de9ff5 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -32,6 +32,11 @@
 #define div_mask(d)((1 << (d->width)) - 1)
 #define is_power_of_two(i) !(i & ~i)
 
+static unsigned int _get_mindiv(struct clk_divider *divider)
+{
+   return divider->min_div;
+}
+
 static unsigned int _get_table_maxdiv(const struct clk_div_table *table)
 {
unsigned int maxdiv = 0;
@@ -148,17 +153,18 @@ static int clk_divider_bestdiv(struct clk_hw *hw, 
unsigned long rate,
 {
struct clk_divider *divider = to_clk_divider(hw);
int i, bestdiv = 0;
-   unsigned long parent_rate, best = 0, now, maxdiv;
+   unsigned long parent_rate, best = 0, now, maxdiv, mindiv;
 
if (!rate)
rate = 1;
 
maxdiv = _get_maxdiv(divider);
+   mindiv = _get_mindiv(divider);
 
if (!(__clk_get_flags(hw->clk) & CLK_SET_RATE_PARENT)) {
parent_rate = *best_parent_rate;
bestdiv = DIV_ROUND_UP(parent_rate, rate);
-   bestdiv = bestdiv == 0 ? 1 : bestdiv;
+   bestdiv = bestdiv == 0 ? mindiv : bestdiv;
bestdiv = bestdiv > maxdiv ? maxdiv : bestdiv;
return bestdiv;
}
@@ -169,7 +175,7 @@ static int clk_divider_bestdiv(struct clk_hw *hw, unsigned 
long rate,
 */
maxdiv = min(ULONG_MAX / rate, maxdiv);
 
-   for (i = 1; i <= maxdiv; i++) {
+   for (i = mindiv; i <= maxdiv; i++) {
if (!_is_valid_div(divider, i))
continue;
parent_rate = __clk_round_rate(__clk_get_parent(hw->clk),
-- 
1.7.12

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

[PATCH 1/2] clk: divider: prepare for minimum divider

[Afzal Mohammed]

Some of clocks can have a limit on minimum divider value that can be
programmed, prepare for such a support.

Add a new field min_div for the basic divider clock. Enhance runtime
registration and static definition helper of basic clock divider so
that minimum divider value can be specified and modify all call sites.

Signed-off-by: Afzal Mohammed 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Russell King 
Cc: Paul Walmsley 
Cc: Tony Lindgren 
Cc: Mike Turquette 
Cc: Viresh Kumar 
Cc: Haojian Zhuang 
Cc: Chao Xie 
Cc: Arnd Bergmann 
---

Based on v3.8-rc3, tested on am335x evm.

 arch/arm/mach-imx/clk-imx6q.c |  4 +-
 arch/arm/mach-imx/clk.h   |  4 +-
 arch/arm/mach-omap2/cclock2420_data.c | 12 +++---
 arch/arm/mach-omap2/cclock2430_data.c |  9 ++--
 arch/arm/mach-omap2/cclock33xx_data.c | 25 ++-
 arch/arm/mach-omap2/cclock3xxx_data.c | 49 +++--
 arch/arm/mach-omap2/cclock44xx_data.c | 81 +--
 drivers/clk/clk-divider.c | 13 +++---
 drivers/clk/clk-ls1x.c|  9 ++--
 drivers/clk/mmp/clk-mmp2.c| 24 +++
 drivers/clk/mmp/clk-pxa168.c  |  3 +-
 drivers/clk/mmp/clk-pxa910.c  |  3 +-
 drivers/clk/spear/spear3xx_clock.c|  6 ++-
 include/linux/clk-private.h   | 16 ---
 include/linux/clk-provider.h  |  7 ++-
 15 files changed, 159 insertions(+), 106 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 7f2c10c..aa901b2 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -218,8 +218,8 @@ int __init mx6q_clocks_init(void)
clk[pcie_ref_125m] = imx_clk_gate("pcie_ref_125m", "pcie_ref", base + 
0xe0, 19);
 
clk[enet_ref] = clk_register_divider_table(NULL, "enet_ref", 
"pll6_enet", 0,
-   base + 0xe0, 0, 2, 0, clk_enet_ref_table,
-   &imx_ccm_lock);
+   base + 0xe0, 0, 2, CLK_DIVIDER_MIN_DIV_DEFAULT, 0,
+   clk_enet_ref_table, &imx_ccm_lock);
 
/*name  parent_name
reg   idx */
clk[pll2_pfd0_352m] = imx_clk_pfd("pll2_pfd0_352m", "pll2_bus", 
base + 0x100, 0);
diff --git a/arch/arm/mach-imx/clk.h b/arch/arm/mach-imx/clk.h
index 9d1f3b9..d09e821 100644
--- a/arch/arm/mach-imx/clk.h
+++ b/arch/arm/mach-imx/clk.h
@@ -56,7 +56,9 @@ static inline struct clk *imx_clk_divider(const char *name, 
const char *parent,
void __iomem *reg, u8 shift, u8 width)
 {
return clk_register_divider(NULL, name, parent, CLK_SET_RATE_PARENT,
-   reg, shift, width, 0, &imx_ccm_lock);
+   reg, shift, width,
+   CLK_DIVIDER_MIN_DIV_DEFAULT, 0,
+   &imx_ccm_lock);
 }
 
 static inline struct clk *imx_clk_gate(const char *name, const char *parent,
diff --git a/arch/arm/mach-omap2/cclock2420_data.c 
b/arch/arm/mach-omap2/cclock2420_data.c
index 7e5febe..2a3d030 100644
--- a/arch/arm/mach-omap2/cclock2420_data.c
+++ b/arch/arm/mach-omap2/cclock2420_data.c
@@ -146,12 +146,12 @@ DEFINE_STRUCT_CLK(core_ck, core_ck_parent_names, 
core_ck_ops);
 DEFINE_CLK_DIVIDER(core_l3_ck, "core_ck", &core_ck, 0x0,
   OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL1),
   OMAP24XX_CLKSEL_L3_SHIFT, OMAP24XX_CLKSEL_L3_WIDTH,
-  CLK_DIVIDER_ONE_BASED, NULL);
+  CLK_DIVIDER_MIN_DIV_DEFAULT, CLK_DIVIDER_ONE_BASED, NULL);
 
 DEFINE_CLK_DIVIDER(l4_ck, "core_l3_ck", &core_l3_ck, 0x0,
   OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL1),
   OMAP24XX_CLKSEL_L4_SHIFT, OMAP24XX_CLKSEL_L4_WIDTH,
-  CLK_DIVIDER_ONE_BASED, NULL);
+  CLK_DIVIDER_MIN_DIV_DEFAULT, CLK_DIVIDER_ONE_BASED, NULL);
 
 static struct clk aes_ick;
 
@@ -1226,7 +1226,7 @@ DEFINE_STRUCT_CLK(mmc_ick, aes_ick_parent_names, 
aes_ick_ops);
 DEFINE_CLK_DIVIDER(mpu_ck, "core_ck", &core_ck, 0x0,
   OMAP_CM_REGADDR(MPU_MOD, CM_CLKSEL),
   OMAP24XX_CLKSEL_MPU_SHIFT, OMAP24XX_CLKSEL_MPU_WIDTH,
-  CLK_DIVIDER_ONE_BASED, NULL);
+  CLK_DIVIDER_MIN_DIV_DEFAULT, CLK_DIVIDER_ONE_BASED, NULL);
 
 static struct clk mpu_wdt_fck;
 
@@ -1470,7 +1470,8 @@ DEFINE_CLK_OMAP_MUX_GATE(sys_clkout_src, "wkup_clkdm", 
common_clkout_src_clksel,
 
 DEFINE_CLK_DIVIDER(sys_clkout, "sys_clkout_src", &sys_clkout_src, 0x0,
   OMAP2420_PRCM_CLKOUT_CTRL, OMAP24XX_CLKOUT_DIV_SHIFT,
-  OMAP24XX_CLKOUT_DIV_WIDTH, CLK_DIVIDER_POWER_OF_TWO, NULL);
+  OMAP24XX_CLKOUT_DIV_WIDTH, CLK_DIVIDER_MIN_DIV_DEFAULT,
+  CLK_DIVIDER_POWER_OF_TWO, NULL);
 
 DEFINE_CLK_OMAP_MUX_GATE(sys_clkout2_src, "wkup_clkdm",
 common_clkout_src_clksel, OMAP2420_PRCM_CLKOUT_CTRL,
@@ -1480,7 +1481,8 @@ DEFINE_CLK_OMA

Re: [PATCH v1 0/6] USB: Add support for multiple PHYs of same type

[kishon]

Hi,

On Tuesday 22 January 2013 09:15 PM, kishon wrote:

On Tuesday 22 January 2013 09:11 PM, Koen Kooi wrote:


Op 22 jan. 2013, om 10:58 heeft Kishon Vijay Abraham I 
het volgende geschreven:


This patch series adds support for adding multiple PHY's (of same type).
The binding information has to be present in the PHY library (otg.c) in
order for it to return the appropriate PHY whenever the USB controller
request for the PHY. So added a new API usb_bind_phy() to pass the
binding
information. This API should be called by platform specific
initialization
code.

So the binding should be done something like
usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto"); specifying
the USB
controller device name, index, and the PHY device name.
I have done this binding for OMAP platforms, but it should be done for
all the platforms.

After this design, the phy can be got by passing the USB controller
device
pointer and the index.

Developed this patch series on
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv
after applying "usb: musb: add driver for control module" patch series
and "ARM: dts: omap: add dt data for MUSB"

Did basic enumeration testing in omap4 panda and omap3 beagle.


With this patchset USB completely breaks on am33xx beaglebone, is that
intended?

Not really.
Does am33xx makes use of omap2430.c? Which PHY does am33xx uses?


I figured out it uses drivers/usb/musb/musb_dsps.c (So it doesn't use 
omap2430.c). I think it uses TWL4030_USB (TPS659x0) as PHY.


Then we need to adapt am33xx to use devm_usb_get_phy_by_phandle.
I'll see how to do it.

Thank you for testing and reporting it :-)

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 v5 00/14] DMA Engine support for AM33XX

[Sekhar Nori]

Hi Tony,

On 1/16/2013 2:02 AM, Matt Porter wrote:

> This series adds DMA Engine support for AM33xx, which uses
> an EDMA DMAC. The EDMA DMAC has been previously supported by only
> a private API implementation (much like the situation with OMAP
> DMA) found on the DaVinci family of SoCs.

Will you take this series through the OMAP tree? Only 1/14 touches
mach-davinci and I am mostly okay with it except some changes I just
requested Matt to make in another thread.

Thanks,
Sekhar
--
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 v1 0/6] USB: Add support for multiple PHYs of same type

[kishon]

On Tuesday 22 January 2013 09:11 PM, Koen Kooi wrote:


Op 22 jan. 2013, om 10:58 heeft Kishon Vijay Abraham I  het 
volgende geschreven:


This patch series adds support for adding multiple PHY's (of same type).
The binding information has to be present in the PHY library (otg.c) in
order for it to return the appropriate PHY whenever the USB controller
request for the PHY. So added a new API usb_bind_phy() to pass the binding
information. This API should be called by platform specific initialization
code.

So the binding should be done something like
usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto"); specifying the USB
controller device name, index, and the PHY device name.
I have done this binding for OMAP platforms, but it should be done for
all the platforms.

After this design, the phy can be got by passing the USB controller device
pointer and the index.

Developed this patch series on
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv
after applying "usb: musb: add driver for control module" patch series
and "ARM: dts: omap: add dt data for MUSB"

Did basic enumeration testing in omap4 panda and omap3 beagle.


With this patchset USB completely breaks on am33xx beaglebone, is that intended?

Not really.
Does am33xx makes use of omap2430.c? Which PHY does am33xx uses?

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 v1 0/6] USB: Add support for multiple PHYs of same type

[Koen Kooi]

Op 22 jan. 2013, om 10:58 heeft Kishon Vijay Abraham I  het 
volgende geschreven:

> This patch series adds support for adding multiple PHY's (of same type).
> The binding information has to be present in the PHY library (otg.c) in
> order for it to return the appropriate PHY whenever the USB controller
> request for the PHY. So added a new API usb_bind_phy() to pass the binding
> information. This API should be called by platform specific initialization
> code.
> 
> So the binding should be done something like
> usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto"); specifying the USB
> controller device name, index, and the PHY device name.
> I have done this binding for OMAP platforms, but it should be done for
> all the platforms.
> 
> After this design, the phy can be got by passing the USB controller device
> pointer and the index.
> 
> Developed this patch series on
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv
> after applying "usb: musb: add driver for control module" patch series
> and "ARM: dts: omap: add dt data for MUSB"
> 
> Did basic enumeration testing in omap4 panda and omap3 beagle.

With this patchset USB completely breaks on am33xx beaglebone, is that intended?


--
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 v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot

[kishon]

Hi,

On Tuesday 22 January 2013 09:08 PM, Peter Ujfalusi wrote:

On 01/22/2013 04:21 PM, kishon wrote:

But it's better to check if deferred probing
takes place whenever a new driver is bound to a device as you just mentioned.


Whenever you load (might be also when you unload) a driver the deferred
modules will try to probe again. This is to check back if the dependency of
the deferred modules has been fulfilled by the new driver or not.


Thanks Peter.

-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: [RFC PATCH v3 02/16] ARM: davinci: move private EDMA API to arm/common

[Sekhar Nori]

Matt,

Sorry about the late reply. I noticed this mail only after I started to
look at v5 of your series :(

On 1/11/2013 5:21 AM, Matt Porter wrote:
> On Sun, Oct 28, 2012 at 01:47:09PM +0530, Sekhar Nori wrote:
>> On 10/18/2012 6:56 PM, Matt Porter wrote:
>>> Move mach-davinci/dma.c to common/edma.c so it can be used
>>> by OMAP (specifically AM33xx) as well. This just moves the
>>> private EDMA API but does not support OMAP.
>>>
>>> Signed-off-by: Matt Porter 
>>> ---
>>
>>> diff --git a/arch/arm/mach-davinci/devices.c 
>>> b/arch/arm/mach-davinci/devices.c
>>> index 4c48a36..f45d591 100644
>>> --- a/arch/arm/mach-davinci/devices.c
>>> +++ b/arch/arm/mach-davinci/devices.c
>>> @@ -19,9 +19,10 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> -#include 
>>>  #include 
>>>  #include 
>>> +#include 
>>
>> Can you please introduce a patch to clean this mixture of linux/ and
>> mach/ includes?
> 
> Yeah, are you ok with a follow on series to clean all these files? I
> don't want to make this series longer with something not dma related
> that's purely cleanup from the great header reorg of 2012.

Okay. I agree doing this sort of change now will cause merge issues.

> 
>>> +
>>>  
>>>  #include "davinci.h"
>>>  #include "clock.h"
>>> @@ -141,10 +142,10 @@ static struct resource mmcsd0_resources[] = {
>>> },
>>> /* DMA channels: RX, then TX */
>>> {
>>> -   .start = EDMA_CTLR_CHAN(0, DAVINCI_DMA_MMCRXEVT),
>>> +   .start = EDMA_CTLR_CHAN(0, 26),
>>
>> Instead of just replacing the event #defines with plain numbers, can you
>> introduce a mach-davinci local edma.h which can then be included in the
>> davinci platform files which refer to edma channel numbers?
> 
> Ok, so when I removed the old edma.h it was full of unused defines and
> we are left with just this one. If I introduced something like that it
> would be used in just one place here. and only for these two values.
> How about we just add a comment?

I prefer adding a local #define in this file. This will keep it
consistent with what is done in arch/arm/mach-davinci/dm365.c for
example. Same for the change in sound/soc/davinci/davinci-sffsdr.c

> 
>>
>>> diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
>>> index 7cd56ed..153fab8 100644
>>> --- a/arch/arm/plat-omap/Kconfig
>>> +++ b/arch/arm/plat-omap/Kconfig
>>> @@ -28,6 +28,7 @@ config ARCH_OMAP2PLUS
>>> select OMAP_DM_TIMER
>>> select PROC_DEVICETREE if PROC_FS
>>> select SPARSE_IRQ
>>> +   select TI_PRIV_EDMA
>>
>> This hunk does not seem to belong to subject of this patch.
> 
> Let me reword the subject/description. The idea of this logical
> chunk was to put everything in place to make it build on OMAP,
> with the expectation that the build fails without the next patch
> in the series.

But this will break bisect. With just this patch applied, omap build
breaks. Looks like it will be more logical to merge this hunk with 3/14
since that's when you really start using the private DMA support on OMAP
platforms.

This issue is a must fix IMO.

I am ok with the patch otherwise. With these changes done, you can add:

Acked-by: Sekhar Nori 

Thanks,
Sekhar
--
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 v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot

[Peter Ujfalusi]

On 01/22/2013 04:21 PM, kishon wrote:
> But it's better to check if deferred probing
> takes place whenever a new driver is bound to a device as you just mentioned.

Whenever you load (might be also when you unload) a driver the deferred
modules will try to probe again. This is to check back if the dependency of
the deferred modules has been fulfilled by the new driver or not.

-- 
Péter
--
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 v1 5/6] usb: otg: add device tree support to otg library

[kishon]

Hi,

On Tuesday 22 January 2013 04:06 PM, Mark Rutland wrote:

+struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
+   const char *phandle, u8 index)
+{
+   struct usb_phy  *phy = NULL, **ptr;
+   unsigned long   flags;
+   struct device_node *node;
+
+   if (!dev->of_node) {
+   dev_dbg(dev, "device does not have a device node entry\n");
+   return ERR_PTR(-EINVAL);
+   }
+
+   node = of_parse_phandle(dev->of_node, phandle, index);
+   if (!node) {
+   dev_dbg(dev, "failed to get %s phandle in %s node\n", phandle,
+   dev->of_node->full_name);
+   return ERR_PTR(-ENODEV);
+   }


At any point past this, node's refcount is incremented (done automatically by
of_parse_phandle => of_find_node_by_phandle).


+
+   ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
+   if (!ptr) {
+   dev_dbg(dev, "failed to allocate memory for devres\n");
+   return ERR_PTR(-ENOMEM);
+   }
+
+   spin_lock_irqsave(&phy_lock, flags);
+
+   phy = __of_usb_find_phy(node);
+   if (IS_ERR(phy) || !try_module_get(phy->dev->driver->owner)) {
+   phy = ERR_PTR(-EPROBE_DEFER);
+   devres_free(ptr);
+   goto err0;
+   }
+
+   *ptr = phy;
+   devres_add(dev, ptr);
+
+   get_device(phy->dev);
+
+err0:
+   spin_unlock_irqrestore(&phy_lock, flags);
+
+   return phy;
+}


This means that on all of the exit paths, node's refcount is left incremented
incorrectly. You'll need an of_node_put(node) on each exit path.


Ok. Will fix it.

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 v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot

[kishon]

On Tuesday 22 January 2013 08:17 PM, Roger Quadros wrote:

On 01/22/2013 04:37 PM, kishon wrote:

On Tuesday 22 January 2013 07:47 PM, Roger Quadros wrote:

On 01/22/2013 11:58 AM, Kishon Vijay Abraham I wrote:

The OMAP glue has been modified to get PHY by phandle for dt boot.

Signed-off-by: Kishon Vijay Abraham I 
---
   drivers/usb/musb/omap2430.c |7 ++-
   1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 1a8cf6d..e43faeb 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -345,7 +345,12 @@ static int omap2430_musb_init(struct musb *musb)
* up through ULPI.  TWL4030-family PMICs include one,
* which needs a driver, drivers aren't always needed.
*/
-musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+if (dev->parent->of_node)
+musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
+"usb_phy", 0);
+else
+musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+
   if (IS_ERR_OR_NULL(musb->xceiv)) {
   pr_err("HS USB OTG: no transceiver configured\n");
   return -ENODEV;


This will not work with PHY driver as a module. You need to use deferred 
probing mechanism here
after you have addressed my comment in patch 2 and also 
devm_usb_get_phy_by_phandle()


IIUC, even using -EPROBE_DEFER might not help if we are making the PHY driver 
as module, since the kernel will try to probe only till the prompt comes.


Oh really? I thought deferred probing takes place whenever a new driver is 
bound to a device.

You might also be right. I'm not so sure.

What does "prompt comes" have to do with it?

I just meant end of boot process. But it's better to check if deferred 
probing takes place whenever a new driver is bound to a device as you 
just mentioned.


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 v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot

[Roger Quadros]

On 01/22/2013 04:37 PM, kishon wrote:
> On Tuesday 22 January 2013 07:47 PM, Roger Quadros wrote:
>> On 01/22/2013 11:58 AM, Kishon Vijay Abraham I wrote:
>>> The OMAP glue has been modified to get PHY by phandle for dt boot.
>>>
>>> Signed-off-by: Kishon Vijay Abraham I 
>>> ---
>>>   drivers/usb/musb/omap2430.c |7 ++-
>>>   1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
>>> index 1a8cf6d..e43faeb 100644
>>> --- a/drivers/usb/musb/omap2430.c
>>> +++ b/drivers/usb/musb/omap2430.c
>>> @@ -345,7 +345,12 @@ static int omap2430_musb_init(struct musb *musb)
>>>* up through ULPI.  TWL4030-family PMICs include one,
>>>* which needs a driver, drivers aren't always needed.
>>>*/
>>> -musb->xceiv = devm_usb_get_phy_dev(dev, 0);
>>> +if (dev->parent->of_node)
>>> +musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
>>> +"usb_phy", 0);
>>> +else
>>> +musb->xceiv = devm_usb_get_phy_dev(dev, 0);
>>> +
>>>   if (IS_ERR_OR_NULL(musb->xceiv)) {
>>>   pr_err("HS USB OTG: no transceiver configured\n");
>>>   return -ENODEV;
>>
>> This will not work with PHY driver as a module. You need to use deferred 
>> probing mechanism here
>> after you have addressed my comment in patch 2 and also 
>> devm_usb_get_phy_by_phandle()
> 
> IIUC, even using -EPROBE_DEFER might not help if we are making the PHY driver 
> as module, since the kernel will try to probe only till the prompt comes.
> 
Oh really? I thought deferred probing takes place whenever a new driver is 
bound to a device. What does "prompt comes" have to do with it?


> And having -EPROBE_DEFER instead of -ENODEV might also not help since, the 
> gadget driver wont be able to bind to UDC (usb_gadget_probe_driver will fail).
> 
> A lot of things need to be changed before we change to -EPROBE_DEFER IMO.

OK.

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

Re: [PATCH v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot

[kishon]

On Tuesday 22 January 2013 07:47 PM, Roger Quadros wrote:

On 01/22/2013 11:58 AM, Kishon Vijay Abraham I wrote:

The OMAP glue has been modified to get PHY by phandle for dt boot.

Signed-off-by: Kishon Vijay Abraham I 
---
  drivers/usb/musb/omap2430.c |7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 1a8cf6d..e43faeb 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -345,7 +345,12 @@ static int omap2430_musb_init(struct musb *musb)
 * up through ULPI.  TWL4030-family PMICs include one,
 * which needs a driver, drivers aren't always needed.
 */
-   musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+   if (dev->parent->of_node)
+   musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
+   "usb_phy", 0);
+   else
+   musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+
if (IS_ERR_OR_NULL(musb->xceiv)) {
pr_err("HS USB OTG: no transceiver configured\n");
return -ENODEV;


This will not work with PHY driver as a module. You need to use deferred 
probing mechanism here
after you have addressed my comment in patch 2 and also 
devm_usb_get_phy_by_phandle()


IIUC, even using -EPROBE_DEFER might not help if we are making the PHY 
driver as module, since the kernel will try to probe only till the 
prompt comes.


And having -EPROBE_DEFER instead of -ENODEV might also not help since, 
the gadget driver wont be able to bind to UDC (usb_gadget_probe_driver 
will fail).


A lot of things need to be changed before we change to -EPROBE_DEFER IMO.

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 v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot

[Roger Quadros]

On 01/22/2013 11:58 AM, Kishon Vijay Abraham I wrote:
> The OMAP glue has been modified to get PHY by phandle for dt boot.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/usb/musb/omap2430.c |7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index 1a8cf6d..e43faeb 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -345,7 +345,12 @@ static int omap2430_musb_init(struct musb *musb)
>* up through ULPI.  TWL4030-family PMICs include one,
>* which needs a driver, drivers aren't always needed.
>*/
> - musb->xceiv = devm_usb_get_phy_dev(dev, 0);
> + if (dev->parent->of_node)
> + musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
> + "usb_phy", 0);
> + else
> + musb->xceiv = devm_usb_get_phy_dev(dev, 0);
> +
>   if (IS_ERR_OR_NULL(musb->xceiv)) {
>   pr_err("HS USB OTG: no transceiver configured\n");
>   return -ENODEV;

This will not work with PHY driver as a module. You need to use deferred 
probing mechanism here
after you have addressed my comment in patch 2 and also 
devm_usb_get_phy_by_phandle()

e.g.

if (IS_ERR(musb->xceiv)) {
int ret = PTR_ERR(musb->xveiv);

if (ret == -ENODEV)
pr_err("HS USB OTG: no transceiver configured\n");

return ret;
}

--
cheers,
-roger
 

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

Re: [PATCH v1 2/6] usb: otg: utils: add facilities in phy lib to support multiple PHYs of same type

[kishon]

Hi,

On Tuesday 22 January 2013 07:37 PM, Roger Quadros wrote:

On 01/22/2013 11:58 AM, Kishon Vijay Abraham I wrote:

In order to add support for multipe PHY's of the same type, new API's
for adding PHY and getting PHY has been added. Now the binding
information for the PHY and controller should be done in platform file
using usb_bind_phy API. And for getting a PHY, the device pointer of the
USB controller and an index should be passed. Based on the binding
information that is added in the platform file, usb_get_phy_dev will return the
appropriate PHY.
Already existing API's to add and get phy by type is not removed. These
API's are deprecated and will be removed once all the platforms start to
use the new API.

Signed-off-by: Kishon Vijay Abraham I 
---
  drivers/usb/otg/otg.c   |  114 ++-
  include/linux/usb/phy.h |   13 ++
  2 files changed, 126 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index 492ba2f..1f30b22 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -36,6 +36,20 @@ static struct usb_phy *__usb_find_phy(struct list_head *list,
return ERR_PTR(-ENODEV);
  }

+static struct usb_phy *__usb_find_phy_dev(struct device *dev,
+   struct list_head *list, u8 index)
+{
+   struct usb_phy_bind *phy_bind = NULL;
+
+   list_for_each_entry(phy_bind, list, list) {
+   if (!(strcmp(phy_bind->dev_name, dev_name(dev))) &&
+   phy_bind->index == index)
+   return phy_bind->phy;


If the PHY driver has not yet called usb_add_phy_dev() (e.g. driver not yet 
loaeded)
then this will return NULL.


+   }
+
+   return ERR_PTR(-ENODEV);
+}
+
  static void devm_usb_phy_release(struct device *dev, void *res)
  {
struct usb_phy *phy = *(struct usb_phy **)res;
@@ -112,6 +126,69 @@ err0:
  EXPORT_SYMBOL(usb_get_phy);

  /**
+ * usb_get_phy_dev - find the USB PHY
+ * @dev - device that requests this phy
+ * @index - the index of the phy
+ *
+ * Returns the phy driver, after getting a refcount to it; or
+ * -ENODEV if there is no such phy.  The caller is responsible for
+ * calling usb_put_phy() to release that count.
+ *
+ * For use by USB host and peripheral drivers.
+ */
+struct usb_phy *usb_get_phy_dev(struct device *dev, u8 index)
+{
+   struct usb_phy  *phy = NULL;
+   unsigned long   flags;
+
+   spin_lock_irqsave(&phy_lock, flags);
+
+   phy = __usb_find_phy_dev(dev, &phy_bind_list, index);
+   if (IS_ERR(phy)) {
+   pr_err("unable to find transceiver\n");
+   goto err0;
+   }


Since NULL is not IS_ERR(), you will do a NULL pointer reference below.

In such cases we would want to use the deferred probe mechanism. So should we 
return
-EPROBE_DEFER?


Good catch. I'll update the patch.

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 v1 4/6] drivers: usb: musb: omap: make use of the new PHY lib APIs

[Roger Quadros]

On 01/22/2013 11:58 AM, Kishon Vijay Abraham I wrote:
> New PHY lib APIs like usb_add_phy_dev() and devm_usb_get_phy_dev() are
> used in MUSB (OMAP), in order to make use of the binding information
> provided in the board file (of OMAP platforms).
> All the platforms should be modified similar to this to add and get the
> PHY.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/usb/musb/omap2430.c   |2 +-
>  drivers/usb/otg/twl4030-usb.c |3 ++-
>  drivers/usb/phy/omap-usb2.c   |3 ++-
>  3 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index bf6cfe0..1a8cf6d 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -345,7 +345,7 @@ static int omap2430_musb_init(struct musb *musb)
>* up through ULPI.  TWL4030-family PMICs include one,
>* which needs a driver, drivers aren't always needed.
>*/
> - musb->xceiv = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> + musb->xceiv = devm_usb_get_phy_dev(dev, 0);
>   if (IS_ERR_OR_NULL(musb->xceiv)) {
>   pr_err("HS USB OTG: no transceiver configured\n");
>   return -ENODEV;
> diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
> index 0a70193..a994715 100644
> --- a/drivers/usb/otg/twl4030-usb.c
> +++ b/drivers/usb/otg/twl4030-usb.c
> @@ -610,6 +610,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
>   twl->phy.dev= twl->dev;
>   twl->phy.label  = "twl4030";
>   twl->phy.otg= otg;
> + twl->phy.type   = USB_PHY_TYPE_USB2;

What is the need to set phy.type? I think this should be deprecated along with 
the old API.

>   twl->phy.set_suspend= twl4030_set_suspend;
>  
>   otg->phy= &twl->phy;
> @@ -624,7 +625,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
>   dev_err(&pdev->dev, "ldo init failed\n");
>   return err;
>   }
> - usb_add_phy(&twl->phy, USB_PHY_TYPE_USB2);
> + usb_add_phy_dev(&twl->phy);
>  
>   platform_set_drvdata(pdev, twl);
>   if (device_create_file(&pdev->dev, &dev_attr_vbus))
> diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
> index 4b59b39..b5c759c 100644
> --- a/drivers/usb/phy/omap-usb2.c
> +++ b/drivers/usb/phy/omap-usb2.c
> @@ -143,6 +143,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
>   phy->phy.label  = "omap-usb2";
>   phy->phy.set_suspend= omap_usb2_suspend;
>   phy->phy.otg= otg;
> + phy->phy.type   = USB_PHY_TYPE_USB2;

same here.

>  
>   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>  
> @@ -168,7 +169,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
>   }
>   clk_prepare(phy->wkupclk);
>  
> - usb_add_phy(&phy->phy, USB_PHY_TYPE_USB2);
> + usb_add_phy_dev(&phy->phy);
>  
>   platform_set_drvdata(pdev, phy);
>  
> 

--
cheers,
-roger

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

Re: [PATCH v1 2/6] usb: otg: utils: add facilities in phy lib to support multiple PHYs of same type

[Roger Quadros]

On 01/22/2013 11:58 AM, Kishon Vijay Abraham I wrote:
> In order to add support for multipe PHY's of the same type, new API's
> for adding PHY and getting PHY has been added. Now the binding
> information for the PHY and controller should be done in platform file
> using usb_bind_phy API. And for getting a PHY, the device pointer of the
> USB controller and an index should be passed. Based on the binding
> information that is added in the platform file, usb_get_phy_dev will return 
> the
> appropriate PHY.
> Already existing API's to add and get phy by type is not removed. These
> API's are deprecated and will be removed once all the platforms start to
> use the new API.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  drivers/usb/otg/otg.c   |  114 
> ++-
>  include/linux/usb/phy.h |   13 ++
>  2 files changed, 126 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
> index 492ba2f..1f30b22 100644
> --- a/drivers/usb/otg/otg.c
> +++ b/drivers/usb/otg/otg.c
> @@ -36,6 +36,20 @@ static struct usb_phy *__usb_find_phy(struct list_head 
> *list,
>   return ERR_PTR(-ENODEV);
>  }
>  
> +static struct usb_phy *__usb_find_phy_dev(struct device *dev,
> + struct list_head *list, u8 index)
> +{
> + struct usb_phy_bind *phy_bind = NULL;
> +
> + list_for_each_entry(phy_bind, list, list) {
> + if (!(strcmp(phy_bind->dev_name, dev_name(dev))) &&
> + phy_bind->index == index)
> + return phy_bind->phy;

If the PHY driver has not yet called usb_add_phy_dev() (e.g. driver not yet 
loaeded)
then this will return NULL.

> + }
> +
> + return ERR_PTR(-ENODEV);
> +}
> +
>  static void devm_usb_phy_release(struct device *dev, void *res)
>  {
>   struct usb_phy *phy = *(struct usb_phy **)res;
> @@ -112,6 +126,69 @@ err0:
>  EXPORT_SYMBOL(usb_get_phy);
>  
>  /**
> + * usb_get_phy_dev - find the USB PHY
> + * @dev - device that requests this phy
> + * @index - the index of the phy
> + *
> + * Returns the phy driver, after getting a refcount to it; or
> + * -ENODEV if there is no such phy.  The caller is responsible for
> + * calling usb_put_phy() to release that count.
> + *
> + * For use by USB host and peripheral drivers.
> + */
> +struct usb_phy *usb_get_phy_dev(struct device *dev, u8 index)
> +{
> + struct usb_phy  *phy = NULL;
> + unsigned long   flags;
> +
> + spin_lock_irqsave(&phy_lock, flags);
> +
> + phy = __usb_find_phy_dev(dev, &phy_bind_list, index);
> + if (IS_ERR(phy)) {
> + pr_err("unable to find transceiver\n");
> + goto err0;
> + }

Since NULL is not IS_ERR(), you will do a NULL pointer reference below.

In such cases we would want to use the deferred probe mechanism. So should we 
return
-EPROBE_DEFER?

> +
> + get_device(phy->dev);
> +
> +err0:
> + spin_unlock_irqrestore(&phy_lock, flags);
> +
> + return phy;
> +}
> +EXPORT_SYMBOL(usb_get_phy_dev);
> +

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

Re: OMAP baseline test results for v3.8-rc4

[Mark Jackson]

On 22/01/13 13:32, Bedia, Vaibhav wrote:



> Following works for me:
> 
> Kernel
> ===
> git checkout next-20130122
> make distclean
> make omap2plus_defconfig
> 
> make -j7
> cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb > 
> arch/arm/boot/zImage-dtb.am335x-bone
> mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 
> 'Linux' -d arch/arm/boot/zImage-dtb.am335x-bone 
> arch/arm/boot/uImage-dtb.am335x-bone
> 
> U-Boot
> ===
> Built from v2013.01



> A dumb question... in your case what's the bootargs set? Note that the 
> mainline
> kernel for AM335x doesn't have MMC support yet and the default bootargs is 
> set to
> rootfs on MMC.

Yes ... I'm trying to boot from a rootfs on MMC:-

Kernel command line: console=ttyO0,115200n8 earlyprintk debug 
root=/dev/mmcblk0p2 ro rootfstype=ext2
rootwait

But I should get *something* from the kernel before it starts trying to access 
the rootfs ?

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

Re: OMAP baseline test results for v3.8-rc4

[Mark Jackson]

On 22/01/13 12:21, Peter Korsgaard wrote:
>> "Mark" == Mark Jackson  writes:
> 
> Hi,
> 
>  Mark> Bytes transferred = 3963919 (3c7c0f hex)
>  Mark> ## Booting kernel from Legacy Image at 8000 ...
>  Mark>Image Name:   Linux
>  Mark>Image Type:   ARM Linux Kernel Image (uncompressed)
>  Mark>Data Size:3963855 Bytes = 3.8 MiB
>  Mark>Load Address: 80008000
>  Mark>Entry Point:  80008000
>  Mark>Verifying Checksum ... OK
>  Mark>Loading Kernel Image ... OK
>  Mark> OK
> 
> I haven't tried a recent -next build, but what is your kernel command
> line and did you try without EARLY_PRINTK?
> 

Kernel command line: console=ttyO0,115200n8 earlyprintk debug 
root=/dev/mmcblk0p2 ro rootfstype=ext2
rootwait

I understand that MMC is not in the mainline.

Aha ... I tried without EARLY_PRINTK and it now boots up to the point of rootfs 
access.

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

RE: OMAP baseline test results for v3.8-rc4

[Bedia, Vaibhav]

On Tue, Jan 22, 2013 at 15:45:08, Mark Jackson wrote:
> On 22/01/13 02:24, Paul Walmsley wrote:
> > 
> > Hi guys,
> > 
> > Regarding the AM33xx test failures with appended DTBs, it would be very 
> > helpful if especially the TI people could try reproducing the problem.
> 
> My non-working setup (I'm using a recent U-Boot) is as follows ...
> 
> [Note that the DTB patch mentioned elsewhere in this thread seems to be 
> *already* applied to -next]
> 
> $ git describe
> next-20130121
> $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- omap2plus_defconfig
> $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- menuconfig
> CONFIG_ARM_APPENDED_DTB=y
> CONFIG_ARM_ATAG_DTB_COMPAT=y
> CONFIG_EARLY_PRINTK=y
> $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux-
> $ cat arch/arm/boot/zImage arch/arm/boot/dtb/am335x-bone.dtb > 
> arch/arm/boot/zImage-dtb.am335x-bone
> $ scripts/mkuboot.sh -A arm -O linux -C none -T kernel -a 0×80008000 -e 
> 0×80008000 -n ‘Linux’ -d
> arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone
> $ cp arch/arm/boot/uImage-dtb.am335x-bone /tftpboot/nanobone/uImage-dtb
> 
> And when I boot:-
> 
> U-Boot SPL 2013.01 (Jan 16 2013 - 15:20:58)
> OMAP SD/MMC: 0
> reading u-boot.img
> reading u-boot.img
> 
> 
> U-Boot 2013.01 (Jan 16 2013 - 15:20:58)
> 
> I2C:   ready
> DRAM:  256 MiB
> WARNING: Caches not enabled
> NAND:  No NAND device found!!!
> 0 MiB
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> *** Warning - readenv() failed, using default environment
> 
> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, 
> HB-ISO Rx, HB-ISO Tx, SoftConn)
> musb-hdrc: MHDRC RTL version 2.0
> musb-hdrc: setup fifo_mode 4
> musb-hdrc: 28/31 max ep, 16384/16384 memory
> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, 
> HB-ISO Rx, HB-ISO Tx, SoftConn)
> musb-hdrc: MHDRC RTL version 2.0
> musb-hdrc: setup fifo_mode 4
> musb-hdrc: 28/31 max ep, 16384/16384 memory
> USB Host mode controller at 47401800 using PIO, IRQ 0
> Net:   cpsw, usb_ether
> Hit any key to stop autoboot:  0
> mmc0 is current device
> SD/MMC found on device 0
> reading uEnv.txt
> 167 bytes read in 3 ms (53.7 KiB/s)
> Loaded environment from uEnv.txt
> Importing environment from mmc ...
> Running uenvcmd ...
> cpsw Waiting for PHY auto negotiation to complete. done
> link up on port 0, speed 100, full duplex
> BOOTP broadcast 1
> BOOTP broadcast 2
> *** Unhandled DHCP Option in OFFER/ACK: 44
> *** Unhandled DHCP Option in OFFER/ACK: 46
> *** Unhandled DHCP Option in OFFER/ACK: 44
> *** Unhandled DHCP Option in OFFER/ACK: 46
> DHCP client bound to address 10.0.0.112
> Using cpsw device
> TFTP from server 10.0.0.100; our IP address is 10.0.0.112
> Filename '/nanobone/uImage-dtb'.
> Load address: 0x8000
> Loading: #
>  #
>  #
>  #
>  ###
>  627.9 KiB/s
> done
> Bytes transferred = 3963919 (3c7c0f hex)
> ## Booting kernel from Legacy Image at 8000 ...
>Image Name:   Linux
>Image Type:   ARM Linux Kernel Image (uncompressed)
>Data Size:3963855 Bytes = 3.8 MiB
>Load Address: 80008000
>Entry Point:  80008000
>Verifying Checksum ... OK
>Loading Kernel Image ... OK
> OK
> 
> Starting kernel ...
> 
> 

Following works for me:

Kernel
===
git checkout next-20130122
make distclean
make omap2plus_defconfig

make -j7
cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb > 
arch/arm/boot/zImage-dtb.am335x-bone
mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 
'Linux' -d arch/arm/boot/zImage-dtb.am335x-bone 
arch/arm/boot/uImage-dtb.am335x-bone

U-Boot
===
Built from v2013.01

Bootlog
===
U-Boot SPL 2013.01 (Jan 22 2013 - 18:47:57)
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img


U-Boot 2013.01 (Jan 22 2013 - 18:47:57)

I2C:   ready
DRAM:  256 MiB
WARNING: Caches not enabled
NAND:  No NAND device found!!!
0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO 
Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk sp

Re: [PATCH 08/10] ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data

[Rajendra Nayak]

Hi Tony,


So I looked at this one with help of Rajendra. We can get rid of the
IRQ and DMA data(needs DMA biding updates) easily. The address
space though is needed since hwmod code uses it to setup the
sysconfig registers.


OK great. The address space tinkering in hwmod code should be
moved to be done in the drivers.

As discussed earlier, there should be a driver specific reset
function driver_xyz_reset() in the driver header file so the
hwmod code can call it too in a late_initcall if no driver is
loaded.


I am a little confused with what you are saying. The hwmod doing
reset of modules (and not relying on drivers doing it) was
mainly for modules which do not have drivers built in (and hence
run a risk of gating system sleep in case the bootloaders left
them in a bad state).
But if the drivers aren't built in (or are built as modules) *then*
hwmod still needs to be able to do reset (maybe in a late_initcall) of
these modules on its own (because there is no driver code to do it).

The other big reason why hwmod would need the address space
tinkering is because it also controls the various OCP master/slave
modes of these modules. Quite often these modes are broken and
need tinkering every time the module is enable/idled and also
need to be restored back to sane values (smart_idle/smart_standby)
post reset. All of this is today handled as part of hwmod and
would defeat the whole purpose of the framework if all this is
moved into drivers.

So completely getting rid of all address space tinkering in hwmod
looks really difficult.

regards,
Rajendra




Extracting that from DT code seems to be really expensive and
ugly [1]. I am yet to try out DMA lines removal but that seems
to be doable by pulling Vinod'd DMA engine branch and updating
DT file.


The overhead here does not matter as it should only happen in a
late_initcall and only for some of the drivers. For that to
happen we just need to go through the list of modules not yet
probed. We also need to have some locking in the driver specific
reset function to avoid races with the loadable modules.


Whats your suggestion on address space part ?


Let's add the code to hwmod to extract it from DT so hwmod code
can call the driver specific reset function defined in the driver
header. That way we can start moving the driver code out of hwmod
one driver at a time.

Note that the ioremapping should be done in the driver specific
reset function, not in hwmod code. We just need to pass the
iorange in a struct resource to the driver specific reset function.

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: OMAP baseline test results for v3.8-rc4

[Bedia, Vaibhav]

Hi,

On Tue, Jan 22, 2013 at 14:25:13, Peter Korsgaard wrote:
> > "Paul" == Paul Walmsley  writes:
> 
>  Paul> Hi guys,
> 
>  Paul> Regarding the AM33xx test failures with appended DTBs, it would
>  Paul> be very helpful if especially the TI people could try reproducing
>  Paul> the problem.  Otherwise it's going to cause problems with merging
>  Paul> any new AM33xx patches, since I won't be able to test them
>  Paul> without additional work.  Plus, this is something that used to
>  Paul> work up until d01e4afd, so something isn't right.
> 
>  Paul> You'll need to use the bootloader that TI originally shipped with
>  Paul> the BeagleBones:
> 
>  Paul> U-Boot 2011.09-9-gcf6e04d (Mar 08 2012 - 17:15:43)
> 
> FYI, my beaglebone came with a slightly different U-Boot:
> 
> U-Boot 2011.09-0-gf63b270-dirty (Nov 14 2011 - 10:37:14)
> 
> But I have the same behaviour. Recent kernels work with a modern U-Boot,
> but not the original. The build I'm doing is very similar to yours:
> 
> git describe
> v3.8-rc4-71-g9a92841
> 
> make ARCH=arm CROSS_COMPILE=arm-linux- omap2plus_defconfig
> echo CONFIG_ARM_APPENDED_DTB=y >> .config
> echo CONFIG_ARM_ATAG_DTB_COMPAT=y >> .config
> yes ''| make ARCH=arm CROSS_COMPILE=arm-linux- oldconfig
> make ARCH=arm CROSS_COMPILE=arm-linux-
> cat arch/arm/boot/dts/am335x-bone.dtb >> arch/arm/boot/zImage
> make ARCH=arm CROSS_COMPILE=arm-linux- uImage
> 
> # old u-boot (ethernet not stable here, so load from sd)
> 
> U-Boot SPL 2011.09-0-gf63b270-dirty (Nov 14 2011 - 10:37:14)
> Texas Instruments Revision detection unimplemented
> No AC power, disabling frequency switch
> OMAP SD/MMC: 0
> reading u-boot.img
> reading u-boot.img
> 
> 
> U-Boot 2011.09-0-gf63b270-dirty (Nov 14 2011 - 10:37:14)
> 
> I2C:   ready
> DRAM:  256 MiB
> No daughter card present
> NAND:  HW ECC Hamming Code selected
> nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x10, Chip ID: 0x10
> No NAND device found!!!
> 0 MiB
> MMC:   OMAP SD/MMC: 0
> *** Warning - readenv() failed, using default environment
> 
> Net:   cpsw
> Hit any key to stop autoboot:  0
> U-Boot# mmc rescan
> U-Boot# fatload mmc 0:1 0x8020 uImage.new
> reading uImage.new
> 
> 3945127 bytes read
> U-Boot# setenv bootargs console=$console
> U-Boot# bootm 0x8020
> ## Booting kernel from Legacy Image at 8020 ...
>Image Name:   Linux-3.8.0-rc4-00071-g9a92841
>Image Type:   ARM Linux Kernel Image (uncompressed)
>Data Size:3945063 Bytes = 3.8 MiB
>Load Address: 80008000
>Entry Point:  80008000
>Verifying Checksum ... OK
>Loading Kernel Image ... OK
> OK
> 
> Starting kernel ...
> 
> And it hangs. With a reasonably modern U-Boot it works:
> 

I just re-built U-Boot from f63b270 and the kernel from 9a92841
using commands similar to Peter's and the kernel boots for me with
the appended DTB.

(For some reason U-Boot version string doesn't have the commit id
and I can't recollect what causes this)

U-Boot SPL 2011.09 (Jan 22 2013 - 18:06:56)
Texas Instruments Revision detection unimplemented
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img


U-Boot 2011.09 (Jan 22 2013 - 16:00:25)

I2C:   ready
DRAM:  256 MiB
WARNING: Caches not enabled
No daughter card present
NAND:  HW ECC Hamming Code selected
nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x10, Chip ID: 0x10
No NAND device found!!!
0 MiB
MMC:   OMAP SD/MMC: 0
*** Warning - readenv() failed, using default environment

Net:   cpsw
Hit any key to stop autoboot:  0
U-Boot#
U-Boot#
U-Boot# setenv bootargs console=$console
U-Boot# setenv serverip 172.24.133.119
U-Boot# setenv bootfile uImage
U-Boot# dhcp 8020
link up on port 0, speed 100, full duplex
BOOTP broadcast 1
DHCP client bound to address 172.24.190.59
Using cpsw device
TFTP from server 172.24.133.119; our IP address is 172.24.190.59; sending 
through gateway 172.24.188.1
Filename 'uImage'.
Load address: 0x8020
Loading: #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 ###
done
Bytes transferred = 3917327 (3bc60f hex)
U-Boot# bootm 0x8020
## Booting kernel from Legacy Image at 8020 ...
   Image Name:   Linux-3.8.0-rc4-00071-g9a92841
   Image T

Re: [PATCH 08/10] ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data

[Benoit Cousson]

Hi Tony,

On 01/21/2013 07:01 PM, Tony Lindgren wrote:
> * Santosh Shilimkar  [130121 07:09]:
>>>
>> So I looked at this one with help of Rajendra. We can get rid of the
>> IRQ and DMA data(needs DMA biding updates) easily. The address
>> space though is needed since hwmod code uses it to setup the
>> sysconfig registers.
> 
> OK great. The address space tinkering in hwmod code should be
> moved to be done in the drivers.
> 
> As discussed earlier, there should be a driver specific reset
> function driver_xyz_reset() in the driver header file so the
> hwmod code can call it too in a late_initcall if no driver is
> loaded.
> 
>> Extracting that from DT code seems to be really expensive and
>> ugly [1]. I am yet to try out DMA lines removal but that seems
>> to be doable by pulling Vinod'd DMA engine branch and updating
>> DT file.
> 
> The overhead here does not matter as it should only happen in a
> late_initcall and only for some of the drivers. For that to
> happen we just need to go through the list of modules not yet
> probed. We also need to have some locking in the driver specific
> reset function to avoid races with the loadable modules.

Mmm, not really, that address is used by *every* hwmod for sysconfig
access. So iterating over every DT nodes for every hwmods seems pretty
ugly and un-optimized.

That being said, it might worth checking the overhead. That will not
make the fix nicer anyway, but at least it will allow a smooth
transition toward a real clean solution. Assuming someone will work on
that later, which might never happen.

Regards,
Benoit

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

Re: [RFC v2 16/18] ARM: OMAP2+: AM33XX: Basic suspend resume support

[Peter Korsgaard]

> "V" == Bedia, Vaibhav  writes:

Hi,

 V> +   memcpy((void *)wkup_m3_context->code, fw->data, fw->size);
 >> 
 >> A size check would be good. I don't know much about the finer details
 >> about the m3 and how it is connected, but don't you need to ensure data
 >> is flushed before resetting the m3?
 >> 

 V> Will add the reg property in the next version. The wkup-m3 memory is
 V> coming via ioremap() so AFAIK it should be ok. I realized that I do
 V> need to replace the memcpy() with memcpy_toio() here.

Ok, thanks.

-- 
Bye, Peter Korsgaard
--
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] ARM: OMAP3: cm-t3517: add MMC support

[Igor Grinberg]

ping!

It has been 1.5 month and we are at rc4 already...

On 01/02/13 09:16, Igor Grinberg wrote:
> ping
> 
> Hi Tony,
> 
> This is a really small addition to improve Paul's tests coverage.
> Can this go into 3.9?
> 
> Thanks
> 
> On 12/07/12 11:05, Igor Grinberg wrote:
>> cm-t3517 uses two MMC interfaces. Add support for both.
>>
>> Signed-off-by: Igor Grinberg 
>> ---
>> v2: Use CONFIG_MMC_OMAP_HS instead of plain CONFIG_MMC, so it will be stubbed
>> out with the same defines as omap_hsmmc_init() function.
>> Fix the !CONFIG_MMC_OMAP_HS case.
>>
>>  arch/arm/mach-omap2/board-cm-t3517.c |   27 +++
>>  1 files changed, 27 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-cm-t3517.c 
>> b/arch/arm/mach-omap2/board-cm-t3517.c
>> index ebbc2ad..792d684 100644
>> --- a/arch/arm/mach-omap2/board-cm-t3517.c
>> +++ b/arch/arm/mach-omap2/board-cm-t3517.c
>> @@ -32,6 +32,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  
>>  #include 
>> @@ -46,6 +47,7 @@
>>  
>>  #include "mux.h"
>>  #include "control.h"
>> +#include "hsmmc.h"
>>  #include "common-board-devices.h"
>>  #include "am35xx-emac.h"
>>  #include "gpmc-nand.h"
>> @@ -121,6 +123,26 @@ static void cm_t3517_init_hecc(void)
>>  static inline void cm_t3517_init_hecc(void) {}
>>  #endif
>>  
>> +#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
>> +static struct omap2_hsmmc_info cm_t3517_mmc[] = {
>> +{
>> +.mmc= 1,
>> +.caps   = MMC_CAP_4_BIT_DATA,
>> +.gpio_cd= 144,
>> +.gpio_wp= 59,
>> +},
>> +{
>> +.mmc= 2,
>> +.caps   = MMC_CAP_4_BIT_DATA,
>> +.gpio_cd= -EINVAL,
>> +.gpio_wp= -EINVAL,
>> +},
>> +{}  /* Terminator */
>> +};
>> +#else
>> +#define cm_t3517_mmc NULL
>> +#endif
>> +
>>  #if defined(CONFIG_RTC_DRV_V3020) || defined(CONFIG_RTC_DRV_V3020_MODULE)
>>  #define RTC_IO_GPIO (153)
>>  #define RTC_WR_GPIO (154)
>> @@ -271,6 +293,10 @@ static struct omap_board_mux board_mux[] __initdata = {
>>  /* CM-T3517 USB HUB nRESET */
>>  OMAP3_MUX(MCBSP4_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
>>  
>> +/* CD - GPIO144 and WP - GPIO59 for MMC1 - SB-T35 */
>> +OMAP3_MUX(UART2_CTS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
>> +OMAP3_MUX(GPMC_CLK, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
>> +
>>  { .reg_offset = OMAP_MUX_TERMINATOR },
>>  };
>>  #endif
>> @@ -286,6 +312,7 @@ static void __init cm_t3517_init(void)
>>  cm_t3517_init_usbh();
>>  cm_t3517_init_hecc();
>>  am35xx_emac_init(AM35XX_DEFAULT_MDIO_FREQUENCY, 1);
>> +omap_hsmmc_init(cm_t3517_mmc);
>>  }
>>  
>>  MACHINE_START(CM_T3517, "Compulab CM-T3517")
> 

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

Re: OMAP baseline test results for v3.8-rc4

[Peter Korsgaard]

> "Mark" == Mark Jackson  writes:

Hi,

 Mark> Bytes transferred = 3963919 (3c7c0f hex)
 Mark> ## Booting kernel from Legacy Image at 8000 ...
 Mark>Image Name:   Linux
 Mark>Image Type:   ARM Linux Kernel Image (uncompressed)
 Mark>Data Size:3963855 Bytes = 3.8 MiB
 Mark>Load Address: 80008000
 Mark>Entry Point:  80008000
 Mark>Verifying Checksum ... OK
 Mark>Loading Kernel Image ... OK
 Mark> OK

I haven't tried a recent -next build, but what is your kernel command
line and did you try without EARLY_PRINTK?

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

Re: OMAP baseline test results for v3.8-rc4

[Peter Korsgaard]

> "Russell" == Russell King <- ARM Linux > writes:

 Russell> Don't rely on that.  Remember, if the compressed image
 Russell> occupies the same location as the decompressed kernel, the
 Russell> decompressor will copy the data to a different location in RAM
 Russell> first - I think at RAM offset + 32K + decompressed kernel
 Russell> size.

Ok, but this is with the exact same kernel image loaded at the same
address for the two cases. The only difference is U-Boot version.

 Russell> So yes, please try the patch in the link above.

I did. No visible difference. Also not with changing the uImage load
address (2M/16M/32M from start of RAM).

-- 
Bye, Peter Korsgaard
--
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 6/6] OF: Introduce DT overlay support.

[Pantelis Antoniou]

Hi

On Jan 22, 2013, at 5:50 AM, David Gibson wrote:

> On Fri, Jan 04, 2013 at 09:31:10PM +0200, Pantelis Antoniou wrote:
>> Introduce DT overlay support.
>> Using this functionality it is possible to dynamically overlay a part of
>> the kernel's tree with another tree that's been dynamically loaded.
>> It is also possible to remove node and properties.
>> 
>> Signed-off-by: Pantelis Antoniou 
>> ---
>> Documentation/devicetree/overlay-notes.txt | 179 +++
>> drivers/of/Kconfig |  10 +
>> drivers/of/Makefile|   1 +
>> drivers/of/overlay.c   | 831 
>> +
>> include/linux/of.h | 107 
>> 5 files changed, 1128 insertions(+)
>> create mode 100644 Documentation/devicetree/overlay-notes.txt
>> create mode 100644 drivers/of/overlay.c
>> 
>> diff --git a/Documentation/devicetree/overlay-notes.txt 
>> b/Documentation/devicetree/overlay-notes.txt
>> new file mode 100644
>> index 000..5289cbb
>> --- /dev/null
>> +++ b/Documentation/devicetree/overlay-notes.txt
>> @@ -0,0 +1,179 @@
>> +Device Tree Overlay Notes
>> +-
>> +
>> +This document describes the implementation of the in-kernel
>> +device tree overlay functionality residing in drivers/of/overlay.c and is a
>> +companion document to Documentation/devicetree/dt-object-internal.txt[1] &
>> +Documentation/devicetree/dynamic-resolution-notes.txt[2]
>> +
>> +How overlays work
>> +-
>> +
>> +A Device Tree's overlay purpose is to modify the kernel's live tree, and
>> +have the modification affecting the state of the the kernel in a way that
>> +is reflecting the changes.
> 
> Um.. I'm having a great deal of trouble parsing that sentence.
> 
>> +Since the kernel mainly deals with devices, any new device node that result
>> +in an active device should have it created while if the device node is 
>> either
>> +disabled or removed all together, the affected device should be 
>> deregistered.
>> +
>> +Lets take an example where we have a foo board with the following base tree
>> +which is taken from [1].
>> +
>> + foo.dts 
>> -
>> +/* FOO platform */
>> +/ {
>> +compatible = "corp,foo";
>> +
>> +/* shared resources */
>> +res: res {
>> +};
>> +
>> +/* On chip peripherals */
>> +ocp: ocp {
>> +/* peripherals that are always instantiated */
>> +peripheral1 { ... };
>> +}
>> +};
>> + foo.dts 
>> -
>> +
>> +The overlay bar.dts, when loaded (and resolved as described in [2]) should
>> +
>> + bar.dts 
>> -
>> +/plugin/;   /* allow undefined label references and record them */
>> +/ {
>> +/* various properties for loader use; i.e. part id etc. */
>> +fragment@0 {
>> +target = <&ocp>;
>> +__overlay__ {
>> +/* bar peripheral */
>> +bar {
>> +compatible = "corp,bar";
>> +... /* various properties and child nodes */
>> +}
>> +};
>> +};
>> +};
>> + bar.dts 
>> -
>> +
>> +result in foo+bar.dts
>> +
>> + foo+bar.dts 
>> -
>> +/* FOO platform + bar peripheral */
>> +/ {
>> +compatible = "corp,foo";
>> +
>> +/* shared resources */
>> +res: res {
>> +};
>> +
>> +/* On chip peripherals */
>> +ocp: ocp {
>> +/* peripherals that are always instantiated */
>> +peripheral1 { ... };
>> +
>> +/* bar peripheral */
>> +bar {
>> +compatible = "corp,bar";
>> +... /* various properties and child nodes */
>> +}
>> +}
>> +};
>> + foo+bar.dts 
>> -
>> +
>> +As a result of the the overlay, a new device node (bar) has been created
>> +so a bar platform device will be registered and if a matching device driver
>> +is loaded the device will be created as expected.
> 
> Hrm.  This all seems rather complicated.  Maybe it needs to be, but
> I'm not entirely convinced yet.
> 
> One other point - both of these patches are assuming that the overlay
> is in the "live tree" format, but it still needs a bunch of extra
> mangling.  Would it simplify things to just go straight from the
> overlay in flat tree form to modifications to the system-wide live
> tree.

Sorry, I can't parse this. You mean apply the over

Re: [PATCH 5/6] OF: Introduce Device Tree resolve support.

[Pantelis Antoniou]

Hi

On Jan 22, 2013, at 6:05 AM, David Gibson wrote:

> On Mon, Jan 21, 2013 at 12:59:15PM +0200, Pantelis Antoniou wrote:
>> Hi David
>> 
>> On Jan 21, 2013, at 6:48 AM, David Gibson wrote:
>> 
>>> On Fri, Jan 04, 2013 at 09:31:09PM +0200, Pantelis Antoniou wrote:
 Introduce support for dynamic device tree resolution.
 Using it, it is possible to prepare a device tree that's
 been loaded on runtime to be modified and inserted at the kernel
 live tree.
 
 Signed-off-by: Pantelis Antoniou 
 ---
 .../devicetree/dynamic-resolution-notes.txt|  25 ++
 drivers/of/Kconfig |   9 +
 drivers/of/Makefile|   1 +
 drivers/of/resolver.c  | 394 
 +
 include/linux/of.h |  17 +
 5 files changed, 446 insertions(+)
 create mode 100644 Documentation/devicetree/dynamic-resolution-notes.txt
 create mode 100644 drivers/of/resolver.c
 
 diff --git a/Documentation/devicetree/dynamic-resolution-notes.txt 
 b/Documentation/devicetree/dynamic-resolution-notes.txt
 new file mode 100644
 index 000..0b396c4
 --- /dev/null
 +++ b/Documentation/devicetree/dynamic-resolution-notes.txt
 @@ -0,0 +1,25 @@
 +Device Tree Dynamic Resolver Notes
 +--
 +
 +This document describes the implementation of the in-kernel
 +Device Tree resolver, residing in drivers/of/resolver.c and is a
 +companion document to Documentation/devicetree/dt-object-internal.txt[1]
 +
 +How the resolver works
 +--
 +
 +The resolver is given as an input an arbitrary tree compiled with the
 +proper dtc option and having a /plugin/ tag. This generates the
 +appropriate __fixups__ & __local_fixups__ nodes as described in [1].
 +
 +In sequence the resolver works by the following steps:
 +
 +1. Get the maximum device tree phandle value from the live tree + 1.
 +2. Adjust all the local phandles of the tree to resolve by that amount.
 +3. Using the __local__fixups__ node information adjust all local 
 references
 +   by the same amount.
 +4. For each property in the __fixups__ node locate the node it references
 +   in the live tree. This is the label used to tag the node.
 +5. Retrieve the phandle of the target of the fixup.
 +5. For each fixup in the property locate the node:property:offset location
 +   and replace it with the phandle value.
>>> 
>>> Hrm.  So, I'm really still not convinced by this approach.
>>> 
>>> First, I think it's unwise to allow overlays to change
>>> essentially anything in the base tree, rather than having the base
>>> tree define sockets of some sort where things can be attached.
>>> 
>> 
>> One could say that the labels define the sockets. It's not just things
>> to be attached, properties might have to change, or something more complex,
>> as we've found out in practice.
> 
> Hrm.  I know a number of these have come up previously in that big
> thread, but can you summarise some of these cases here.  If things
> need modification in the base tree that still seems to me like the
> base tree hasn't properly described the socket arrangement (I realise
> that allowing such descriptions may require extensions to some of our
> device tree conventions).
> 

It would be pointless to number all the use-cases that Grant put in that
long document, but I can summarize the cases that we've seen on the bone.

* Addition of child device nodes to the ocp node, creates new platform
devices of various kind (audio/video/pwms/timers) - almost any kind of
platform device that the SoC supports. Removing the overlay unregisters
the devices (but precious few drivers support that cleanly ATM). Since
the capes don't support hotplug that's not a big deal.

* Addition of pinctrl configuration nodes.

* Addition of i2c/spi etc device nodes and modification of the parent's
node status property to "okay", creates the bus platform device & registers
the devices on the bus. Slight complication with i2c client devices which
are not platform devices need special handling.

* Modification of configuration parameters of a disabled device and subsequent
enablement. 

>> As far as the unwise part, a good deal of care has been taken so that 
>> people that don't use the overlay functionality have absolutely no
>> overhead, or anything modified in the way they use DT.
> 
> Yeah, that's not what I'm concerned about.  I'm concerned about hard
> to debug problems because some subtle change in the base tree or the
> overlay or both causes the overlay to alter something in the base tree
> it really shouldn't.
> 

Define shouldn't. Let's say someone inserts a bogus overlay that makes the 
system
fail, or misbehave in some other manner. What is the different between 
using the overlay and insert

Re: [PATCH 2/5] ARM: dts: twl6030: Add PWM support

[Benoit Cousson]

On 01/22/2013 11:49 AM, Peter Ujfalusi wrote:
> HI Benoit,
> 
> On 01/22/2013 11:39 AM, Benoit Cousson wrote:
>>> +
>>> +   twl_pwm: pwm {
>>> +   /* provides two PWMs (id 0, 1 for PWM1 and PWM2) */
>>> +   compatible = "ti,twl6030-pwm";
>>> +   #pwm-cells = <2>;
>>> +   };
>>> +
>>> +   twl_pwmled: pwmled {
>>> +   /* provides one PWM (id 0 for Charing indicator LED) */
>>
>> typo: charging.
> 
> Aargh. Corrected in the branch.

Thanks,

Pulled and pushed into 
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git 
for_3.9/dts

Regards,
Benoit

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

Re: [PATCH 2/5] ARM: dts: twl6030: Add PWM support

[Peter Ujfalusi]

HI Benoit,

On 01/22/2013 11:39 AM, Benoit Cousson wrote:
>> +
>> +twl_pwm: pwm {
>> +/* provides two PWMs (id 0, 1 for PWM1 and PWM2) */
>> +compatible = "ti,twl6030-pwm";
>> +#pwm-cells = <2>;
>> +};
>> +
>> +twl_pwmled: pwmled {
>> +/* provides one PWM (id 0 for Charing indicator LED) */
> 
> typo: charging.

Aargh. Corrected in the branch.

Thanks,
Péter
--
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/5] ARM: dts: twl6030: Add PWM support

[Benoit Cousson]

Hi Peter,

Just one minor typo here.

On 01/18/2013 03:36 PM, Peter Ujfalusi wrote:
> Enable support for the PWMs and LED as PWM drivers.
> 
> Signed-off-by: Peter Ujfalusi 
> ---
>  arch/arm/boot/dts/twl6030.dtsi | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
> index 9996cfc..d9b8b21 100644
> --- a/arch/arm/boot/dts/twl6030.dtsi
> +++ b/arch/arm/boot/dts/twl6030.dtsi
> @@ -91,4 +91,16 @@
>   compatible = "ti,twl6030-usb";
>   interrupts = <4>, <10>;
>   };
> +
> + twl_pwm: pwm {
> + /* provides two PWMs (id 0, 1 for PWM1 and PWM2) */
> + compatible = "ti,twl6030-pwm";
> + #pwm-cells = <2>;
> + };
> +
> + twl_pwmled: pwmled {
> + /* provides one PWM (id 0 for Charing indicator LED) */

typo: charging.

Regards,
Benoit

> + compatible = "ti,twl6030-pwmled";
> + #pwm-cells = <2>;
> + };
>  };
> 

--
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 v1 5/6] usb: otg: add device tree support to otg library

[Mark Rutland]

> +struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
> + const char *phandle, u8 index)
> +{
> + struct usb_phy  *phy = NULL, **ptr;
> + unsigned long   flags;
> + struct device_node *node;
> +
> + if (!dev->of_node) {
> + dev_dbg(dev, "device does not have a device node entry\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + node = of_parse_phandle(dev->of_node, phandle, index);
> + if (!node) {
> + dev_dbg(dev, "failed to get %s phandle in %s node\n", phandle,
> + dev->of_node->full_name);
> + return ERR_PTR(-ENODEV);
> + }

At any point past this, node's refcount is incremented (done automatically by
of_parse_phandle => of_find_node_by_phandle).

> +
> + ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
> + if (!ptr) {
> + dev_dbg(dev, "failed to allocate memory for devres\n");
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + spin_lock_irqsave(&phy_lock, flags);
> +
> + phy = __of_usb_find_phy(node);
> + if (IS_ERR(phy) || !try_module_get(phy->dev->driver->owner)) {
> + phy = ERR_PTR(-EPROBE_DEFER);
> + devres_free(ptr);
> + goto err0;
> + }
> +
> + *ptr = phy;
> + devres_add(dev, ptr);
> +
> + get_device(phy->dev);
> +
> +err0:
> + spin_unlock_irqrestore(&phy_lock, flags);
> +
> + return phy;
> +}

This means that on all of the exit paths, node's refcount is left incremented
incorrectly. You'll need an of_node_put(node) on each exit path.

Thanks,
Mark.

--
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 0/5] ARM: dts: OMAP3+: PWM support for TWL and selected boards

[Benoit Cousson]

Hi Peter,

On 01/22/2013 11:11 AM, Peter Ujfalusi wrote:
> Hi Benoit,
> 
> I have prepared for you a branch from where you can pull this set on top of
> mainline v3.8-rc4:

Cool thanks,
I'll merged it in my branch.

Thanks,
Benoit

> 
> Regards,
> Péter
> 
> ---
> The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619:
> 
>   Linux 3.8-rc4 (2013-01-17 19:25:45 -0800)
> 
> are available in the git repository at:
> 
>   git://gitorious.org/omap-audio/linux-audio.git peter/for-benoit
> 
> for you to fetch changes up to b6230ae20bc018d042d703d0667ba9e7ac027ccb:
> 
>   ARM: dts: omap4-sdp: Add support for pwm-backlight (2013-01-22 11:08:37 
> +0100)
> 
> 
> Peter Ujfalusi (5):
>   ARM: dts: twl4030: Add PWM support
>   ARM: dts: twl6030: Add PWM support
>   ARM: dts: omap3-beagle-xm: Use pwm-leds for pmu_stat LED
>   ARM: dts: omap4-sdp: Add support for pwm-leds (keypad and charging LED)
>   ARM: dts: omap4-sdp: Add support for pwm-backlight
> 
>  arch/arm/boot/dts/omap3-beagle-xm.dts | 14 ++
>  arch/arm/boot/dts/omap4-sdp.dts   | 26 ++
>  arch/arm/boot/dts/twl4030.dtsi| 10 ++
>  arch/arm/boot/dts/twl6030.dtsi| 12 
>  4 files changed, 58 insertions(+), 4 deletions(-)
> 
> On 01/18/2013 03:36 PM, Peter Ujfalusi wrote:
>> Hi,
>>
>> Add the needed DT sections for twl4030 and twl6030 for the PWM childs.
>> Update the omap4-sdp to have working backlight and keypad/charging LED 
>> support.
>> Use the pwm-leds driver on BeagleBoard for the pmu_stat LED instead of the 
>> hacky
>> twl403-gpio mapped PWM.
>>
>> Regards,
>> Peter
>> ---
>> Peter Ujfalusi (5):
>>   ARM: dts: twl4030: Add PWM support
>>   ARM: dts: twl6030: Add PWM support
>>   ARM: dts: omap3-beagle-xm: Use pwm-leds for pmu_stat LED
>>   ARM: dts: omap4-sdp: Add support for pwm-leds (keypad and charging LED)
>>   ARM: dts: omap4-sdp: Add support for pwm-backlight
>>
>>  arch/arm/boot/dts/omap3-beagle-xm.dts | 14 ++
>>  arch/arm/boot/dts/omap4-sdp.dts   | 26 ++
>>  arch/arm/boot/dts/twl4030.dtsi| 10 ++
>>  arch/arm/boot/dts/twl6030.dtsi| 12 
>>  4 files changed, 58 insertions(+), 4 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: OMAP baseline test results for v3.8-rc4

[Mark Jackson]

On 22/01/13 02:24, Paul Walmsley wrote:
> 
> Hi guys,
> 
> Regarding the AM33xx test failures with appended DTBs, it would be very 
> helpful if especially the TI people could try reproducing the problem.

My non-working setup (I'm using a recent U-Boot) is as follows ...

[Note that the DTB patch mentioned elsewhere in this thread seems to be 
*already* applied to -next]

$ git describe
next-20130121
$ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- omap2plus_defconfig
$ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- menuconfig
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_EARLY_PRINTK=y
$ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux-
$ cat arch/arm/boot/zImage arch/arm/boot/dtb/am335x-bone.dtb > 
arch/arm/boot/zImage-dtb.am335x-bone
$ scripts/mkuboot.sh -A arm -O linux -C none -T kernel -a 0×80008000 -e 
0×80008000 -n ‘Linux’ -d
arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone
$ cp arch/arm/boot/uImage-dtb.am335x-bone /tftpboot/nanobone/uImage-dtb

And when I boot:-

U-Boot SPL 2013.01 (Jan 16 2013 - 15:20:58)
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img


U-Boot 2013.01 (Jan 16 2013 - 15:20:58)

I2C:   ready
DRAM:  256 MiB
WARNING: Caches not enabled
NAND:  No NAND device found!!!
0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO 
Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO 
Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net:   cpsw, usb_ether
Hit any key to stop autoboot:  0
mmc0 is current device
SD/MMC found on device 0
reading uEnv.txt
167 bytes read in 3 ms (53.7 KiB/s)
Loaded environment from uEnv.txt
Importing environment from mmc ...
Running uenvcmd ...
cpsw Waiting for PHY auto negotiation to complete. done
link up on port 0, speed 100, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
*** Unhandled DHCP Option in OFFER/ACK: 44
*** Unhandled DHCP Option in OFFER/ACK: 46
*** Unhandled DHCP Option in OFFER/ACK: 44
*** Unhandled DHCP Option in OFFER/ACK: 46
DHCP client bound to address 10.0.0.112
Using cpsw device
TFTP from server 10.0.0.100; our IP address is 10.0.0.112
Filename '/nanobone/uImage-dtb'.
Load address: 0x8000
Loading: #
 #
 #
 #
 ###
 627.9 KiB/s
done
Bytes transferred = 3963919 (3c7c0f hex)
## Booting kernel from Legacy Image at 8000 ...
   Image Name:   Linux
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3963855 Bytes = 3.8 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

--
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 0/5] ARM: dts: OMAP3+: PWM support for TWL and selected boards

[Peter Ujfalusi]

Hi Benoit,

I have prepared for you a branch from where you can pull this set on top of
mainline v3.8-rc4:

Regards,
Péter

---
The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619:

  Linux 3.8-rc4 (2013-01-17 19:25:45 -0800)

are available in the git repository at:

  git://gitorious.org/omap-audio/linux-audio.git peter/for-benoit

for you to fetch changes up to b6230ae20bc018d042d703d0667ba9e7ac027ccb:

  ARM: dts: omap4-sdp: Add support for pwm-backlight (2013-01-22 11:08:37 +0100)


Peter Ujfalusi (5):
  ARM: dts: twl4030: Add PWM support
  ARM: dts: twl6030: Add PWM support
  ARM: dts: omap3-beagle-xm: Use pwm-leds for pmu_stat LED
  ARM: dts: omap4-sdp: Add support for pwm-leds (keypad and charging LED)
  ARM: dts: omap4-sdp: Add support for pwm-backlight

 arch/arm/boot/dts/omap3-beagle-xm.dts | 14 ++
 arch/arm/boot/dts/omap4-sdp.dts   | 26 ++
 arch/arm/boot/dts/twl4030.dtsi| 10 ++
 arch/arm/boot/dts/twl6030.dtsi| 12 
 4 files changed, 58 insertions(+), 4 deletions(-)

On 01/18/2013 03:36 PM, Peter Ujfalusi wrote:
> Hi,
> 
> Add the needed DT sections for twl4030 and twl6030 for the PWM childs.
> Update the omap4-sdp to have working backlight and keypad/charging LED 
> support.
> Use the pwm-leds driver on BeagleBoard for the pmu_stat LED instead of the 
> hacky
> twl403-gpio mapped PWM.
> 
> Regards,
> Peter
> ---
> Peter Ujfalusi (5):
>   ARM: dts: twl4030: Add PWM support
>   ARM: dts: twl6030: Add PWM support
>   ARM: dts: omap3-beagle-xm: Use pwm-leds for pmu_stat LED
>   ARM: dts: omap4-sdp: Add support for pwm-leds (keypad and charging LED)
>   ARM: dts: omap4-sdp: Add support for pwm-backlight
> 
>  arch/arm/boot/dts/omap3-beagle-xm.dts | 14 ++
>  arch/arm/boot/dts/omap4-sdp.dts   | 26 ++
>  arch/arm/boot/dts/twl4030.dtsi| 10 ++
>  arch/arm/boot/dts/twl6030.dtsi| 12 
>  4 files changed, 58 insertions(+), 4 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: [RFC PATCH] gpio/omap: fix pm_runtime for IRQ functions

[Linus Walleij]

On Tue, Jan 22, 2013 at 10:54 AM, Rajendra Nayak  wrote:
> On Tuesday 22 January 2013 01:52 PM, Linus Walleij wrote:
>>
>> In the Nomadik I had a similar situation with a GPIO used for the
>> ethernet IRQ. I put the GPIO number in a special board-specific
>> node and added this to the machine,
>
> Thanks Linus. Are there any bindings already available on how these
> special board-specific nodes can be defined in the dts files?

No generic bindings as they are per definition board-specific.

So in the Nomadik case it looks like this:

/* Custom board node with GPIO pins to active etc */
usb-s8815 {
/* The S8815 is using this very GPIO pin for the SMSC91x IRQs */
ethernet-gpio {
gpios = <&gpio3 19 0x1>;
interrupts = <19 0x1>;
interrupt-parent = <&gpio3>;
};
/* This will bias the MMC/SD card detect line */
mmcsd-gpio {
gpios = <&gpio3 16 0x1>;
};
};

First I added custom nodes to the IP blocks, but it was no good idea
as it's not generic for that driver at all, just a board pecularity.

> Are there any using some such in the mainline already?

I just sent a pull request for the Nomadik example but I don't
know about any others.

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

[GIT PULL] ARM: OMAP: Audio support via omap-twl4030 and pwm support

[Peter Ujfalusi]

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.

Regards,
Péter

---
The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619:

  Linux 3.8-rc4 (2013-01-17 19:25:45 -0800)

are available in the git repository at:

  git://gitorious.org/omap-audio/linux-audio.git peter/for-tony

for you to fetch changes up to e4f4e8bfa47431b91fbb21dd9b86d9bc2c15cbd7:

  ARM: board-zoom: Do not request LCD panel enable GPIO from twl4030 
(2013-01-22 10:35:16 +0100)


Peter Ujfalusi (9):
  ARM: OMAP: 3430sdp: Enable extmute functionality for audio
  ARM: OMAP: zoom: Zoom2 does not have extmute functionality
  ARM: OMAP2+: twl-common: Add default twl4030 audio configuration
  ARM: OMAP2+: twl-common: Allow boards to customize the twl4030 audio setup
  ARM: OMAP: zoom: Audio support via the common omap-twl4030 machine driver
  ARM: OMAP: sdp3430: Audio support via the common omap-twl4030 machine 
driver
  ARM: OMAP: board-4430sdp: Proper support for TWL6030 PWM LED/Backlight
  ARM: OMAP: omap3beagle: Use the pwm_leds driver to control the PMU_STAT 
led
  ARM: board-zoom: Do not request LCD panel enable GPIO from twl4030

 arch/arm/mach-omap2/board-3430sdp.c  | 20 
 arch/arm/mach-omap2/board-4430sdp.c  | 30 
+-
 arch/arm/mach-omap2/board-cm-t35.c   |  2 +-
 arch/arm/mach-omap2/board-devkit8000.c   |  2 +-
 arch/arm/mach-omap2/board-igep0020.c |  2 +-
 arch/arm/mach-omap2/board-omap3beagle.c  | 41 
-
 arch/arm/mach-omap2/board-omap3evm.c |  2 +-
 arch/arm/mach-omap2/board-overo.c|  2 +-
 arch/arm/mach-omap2/board-zoom-peripherals.c | 39 
+--
 arch/arm/mach-omap2/twl-common.c | 17 +++--
 arch/arm/mach-omap2/twl-common.h |  3 ++-
 11 files changed, 120 insertions(+), 40 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

[PATCH v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot

[Kishon Vijay Abraham I]

The OMAP glue has been modified to get PHY by phandle for dt boot.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/musb/omap2430.c |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 1a8cf6d..e43faeb 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -345,7 +345,12 @@ static int omap2430_musb_init(struct musb *musb)
 * up through ULPI.  TWL4030-family PMICs include one,
 * which needs a driver, drivers aren't always needed.
 */
-   musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+   if (dev->parent->of_node)
+   musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
+   "usb_phy", 0);
+   else
+   musb->xceiv = devm_usb_get_phy_dev(dev, 0);
+
if (IS_ERR_OR_NULL(musb->xceiv)) {
pr_err("HS USB OTG: no transceiver configured\n");
return -ENODEV;
-- 
1.7.9.5

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

[PATCH v1 3/6] ARM: OMAP: USB: Add phy binding information

[Kishon Vijay Abraham I]

This is w.r.t the changes in PHY library to support adding and getting
multiple PHYs of the same type. In the new design, the
binding information between the PHY and the USB controller should be
specified in the platform specific initialization code. So it's been
done here for OMAP platforms.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/mach-omap2/board-2430sdp.c  |2 ++
 arch/arm/mach-omap2/board-3430sdp.c  |2 ++
 arch/arm/mach-omap2/board-4430sdp.c  |2 ++
 arch/arm/mach-omap2/board-cm-t35.c   |2 ++
 arch/arm/mach-omap2/board-devkit8000.c   |2 ++
 arch/arm/mach-omap2/board-igep0020.c |2 ++
 arch/arm/mach-omap2/board-ldp.c  |2 ++
 arch/arm/mach-omap2/board-omap3beagle.c  |2 ++
 arch/arm/mach-omap2/board-omap3evm.c |2 ++
 arch/arm/mach-omap2/board-omap3logic.c   |2 ++
 arch/arm/mach-omap2/board-omap3pandora.c |2 ++
 arch/arm/mach-omap2/board-omap3stalker.c |2 ++
 arch/arm/mach-omap2/board-omap3touchbook.c   |2 ++
 arch/arm/mach-omap2/board-omap4panda.c   |2 ++
 arch/arm/mach-omap2/board-overo.c|2 ++
 arch/arm/mach-omap2/board-rm680.c|2 ++
 arch/arm/mach-omap2/board-zoom-peripherals.c |2 ++
 17 files changed, 34 insertions(+)

diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
b/arch/arm/mach-omap2/board-2430sdp.c
index 4815ea6..1337f2c 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -263,6 +264,7 @@ static void __init omap_2430sdp_init(void)
omap_hsmmc_init(mmc);
 
omap_mux_init_signal("usb0hs_stp", OMAP_PULL_ENA | OMAP_PULL_UP);
+   usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
 
board_smc91x_init();
diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index bb73afc..8a2e242 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -579,6 +580,7 @@ static void __init omap_3430sdp_init(void)
omap_ads7846_init(1, gpio_pendown, 310, NULL);
omap_serial_init();
omap_sdrc_init(hyb18m512160af6_sdrc_params, NULL);
+   usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
board_smc91x_init();
board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 1cc6696..8e8efcc 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -696,6 +697,7 @@ static void __init omap_4430sdp_init(void)
omap4_sdp4430_wifi_init();
omap4_twl6030_hsmmc_init(mmc);
 
+   usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
usb_musb_init(&musb_board_data);
 
status = omap_ethernet_init();
diff --git a/arch/arm/mach-omap2/board-cm-t35.c 
b/arch/arm/mach-omap2/board-cm-t35.c
index b3102c2..f1172f2 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -724,6 +725,7 @@ static void __init cm_t3x_common_init(void)
cm_t35_init_display();
omap_twl4030_audio_init("cm-t3x");
 
+   usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
cm_t35_init_usbh();
cm_t35_init_camera();
diff --git a/arch/arm/mach-omap2/board-devkit8000.c 
b/arch/arm/mach-omap2/board-devkit8000.c
index 12865af..77cade52 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -622,6 +623,7 @@ static void __init devkit8000_init(void)
 
omap_ads7846_init(2, OMAP3_DEVKIT_TS_GPIO, 0, NULL);
 
+   usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
usbhs_init(&usbhs_bdata);
board_nand_init(devkit8000_nand_partitions,
diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index 0f24cb8..15e5881 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -625,6 +626,7 @@ static void __init igep_init(void)
omap_serial_init();
omap_sdrc_init(m65kam_sdrc_params,
  m65kam_sdrc_params);
+   usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
usb_musb_init(NULL);
 
igep_flash_init();
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board

[PATCH v1 4/6] drivers: usb: musb: omap: make use of the new PHY lib APIs

[Kishon Vijay Abraham I]

New PHY lib APIs like usb_add_phy_dev() and devm_usb_get_phy_dev() are
used in MUSB (OMAP), in order to make use of the binding information
provided in the board file (of OMAP platforms).
All the platforms should be modified similar to this to add and get the
PHY.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/musb/omap2430.c   |2 +-
 drivers/usb/otg/twl4030-usb.c |3 ++-
 drivers/usb/phy/omap-usb2.c   |3 ++-
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index bf6cfe0..1a8cf6d 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -345,7 +345,7 @@ static int omap2430_musb_init(struct musb *musb)
 * up through ULPI.  TWL4030-family PMICs include one,
 * which needs a driver, drivers aren't always needed.
 */
-   musb->xceiv = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+   musb->xceiv = devm_usb_get_phy_dev(dev, 0);
if (IS_ERR_OR_NULL(musb->xceiv)) {
pr_err("HS USB OTG: no transceiver configured\n");
return -ENODEV;
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 0a70193..a994715 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -610,6 +610,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
twl->phy.dev= twl->dev;
twl->phy.label  = "twl4030";
twl->phy.otg= otg;
+   twl->phy.type   = USB_PHY_TYPE_USB2;
twl->phy.set_suspend= twl4030_set_suspend;
 
otg->phy= &twl->phy;
@@ -624,7 +625,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "ldo init failed\n");
return err;
}
-   usb_add_phy(&twl->phy, USB_PHY_TYPE_USB2);
+   usb_add_phy_dev(&twl->phy);
 
platform_set_drvdata(pdev, twl);
if (device_create_file(&pdev->dev, &dev_attr_vbus))
diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
index 4b59b39..b5c759c 100644
--- a/drivers/usb/phy/omap-usb2.c
+++ b/drivers/usb/phy/omap-usb2.c
@@ -143,6 +143,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy->phy.label  = "omap-usb2";
phy->phy.set_suspend= omap_usb2_suspend;
phy->phy.otg= otg;
+   phy->phy.type   = USB_PHY_TYPE_USB2;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
 
@@ -168,7 +169,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
}
clk_prepare(phy->wkupclk);
 
-   usb_add_phy(&phy->phy, USB_PHY_TYPE_USB2);
+   usb_add_phy_dev(&phy->phy);
 
platform_set_drvdata(pdev, phy);
 
-- 
1.7.9.5

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

[PATCH v1 2/6] usb: otg: utils: add facilities in phy lib to support multiple PHYs of same type

[Kishon Vijay Abraham I]

In order to add support for multipe PHY's of the same type, new API's
for adding PHY and getting PHY has been added. Now the binding
information for the PHY and controller should be done in platform file
using usb_bind_phy API. And for getting a PHY, the device pointer of the
USB controller and an index should be passed. Based on the binding
information that is added in the platform file, usb_get_phy_dev will return the
appropriate PHY.
Already existing API's to add and get phy by type is not removed. These
API's are deprecated and will be removed once all the platforms start to
use the new API.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/otg/otg.c   |  114 ++-
 include/linux/usb/phy.h |   13 ++
 2 files changed, 126 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index 492ba2f..1f30b22 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -36,6 +36,20 @@ static struct usb_phy *__usb_find_phy(struct list_head *list,
return ERR_PTR(-ENODEV);
 }
 
+static struct usb_phy *__usb_find_phy_dev(struct device *dev,
+   struct list_head *list, u8 index)
+{
+   struct usb_phy_bind *phy_bind = NULL;
+
+   list_for_each_entry(phy_bind, list, list) {
+   if (!(strcmp(phy_bind->dev_name, dev_name(dev))) &&
+   phy_bind->index == index)
+   return phy_bind->phy;
+   }
+
+   return ERR_PTR(-ENODEV);
+}
+
 static void devm_usb_phy_release(struct device *dev, void *res)
 {
struct usb_phy *phy = *(struct usb_phy **)res;
@@ -112,6 +126,69 @@ err0:
 EXPORT_SYMBOL(usb_get_phy);
 
 /**
+ * usb_get_phy_dev - find the USB PHY
+ * @dev - device that requests this phy
+ * @index - the index of the phy
+ *
+ * Returns the phy driver, after getting a refcount to it; or
+ * -ENODEV if there is no such phy.  The caller is responsible for
+ * calling usb_put_phy() to release that count.
+ *
+ * For use by USB host and peripheral drivers.
+ */
+struct usb_phy *usb_get_phy_dev(struct device *dev, u8 index)
+{
+   struct usb_phy  *phy = NULL;
+   unsigned long   flags;
+
+   spin_lock_irqsave(&phy_lock, flags);
+
+   phy = __usb_find_phy_dev(dev, &phy_bind_list, index);
+   if (IS_ERR(phy)) {
+   pr_err("unable to find transceiver\n");
+   goto err0;
+   }
+
+   get_device(phy->dev);
+
+err0:
+   spin_unlock_irqrestore(&phy_lock, flags);
+
+   return phy;
+}
+EXPORT_SYMBOL(usb_get_phy_dev);
+
+/**
+ * devm_usb_get_phy_dev - find the USB PHY using device ptr and index
+ * @dev - device that requests this phy
+ * @index - the index of the phy
+ *
+ * Gets the phy using usb_get_phy_dev(), and associates a device with it using
+ * devres. On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ *
+ * For use by USB host and peripheral drivers.
+ */
+struct usb_phy *devm_usb_get_phy_dev(struct device *dev, u8 index)
+{
+   struct usb_phy **ptr, *phy;
+
+   ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
+   if (!ptr)
+   return NULL;
+
+   phy = usb_get_phy_dev(dev, index);
+   if (!IS_ERR(phy)) {
+   *ptr = phy;
+   devres_add(dev, ptr);
+   } else
+   devres_free(ptr);
+
+   return phy;
+}
+EXPORT_SYMBOL(devm_usb_get_phy_dev);
+
+/**
  * devm_usb_put_phy - release the USB PHY
  * @dev - device that wants to release this phy
  * @phy - the phy returned by devm_usb_get_phy()
@@ -186,6 +263,36 @@ out:
 EXPORT_SYMBOL(usb_add_phy);
 
 /**
+ * usb_add_phy_dev - declare the USB PHY
+ * @x: the USB phy to be used; or NULL
+ *
+ * This call is exclusively for use by phy drivers, which
+ * coordinate the activities of drivers for host and peripheral
+ * controllers, and in some cases for VBUS current regulation.
+ */
+int usb_add_phy_dev(struct usb_phy *x)
+{
+   struct usb_phy_bind *phy_bind;
+   unsigned long flags;
+
+   if (!x->dev) {
+   dev_err(x->dev, "no device provided for PHY\n");
+   return -EINVAL;
+   }
+
+   spin_lock_irqsave(&phy_lock, flags);
+   list_for_each_entry(phy_bind, &phy_bind_list, list)
+   if (!(strcmp(phy_bind->phy_dev_name, dev_name(x->dev
+   phy_bind->phy = x;
+
+   list_add_tail(&x->head, &phy_list);
+
+   spin_unlock_irqrestore(&phy_lock, flags);
+   return 0;
+}
+EXPORT_SYMBOL(usb_add_phy_dev);
+
+/**
  * usb_remove_phy - remove the OTG PHY
  * @x: the USB OTG PHY to be removed;
  *
@@ -194,10 +301,15 @@ EXPORT_SYMBOL(usb_add_phy);
 void usb_remove_phy(struct usb_phy *x)
 {
unsigned long   flags;
+   struct usb_phy_bind *phy_bind;
 
spin_lock_irqsave(&phy_lock, flags);
-   if (x)
+   if (x) {
+   list_for_each_entry(phy_bind, &phy_bind_list, list)
+   if (phy_bind-

[PATCH v1 1/6] usb: otg: Add an API to bind the USB controller and PHY

[Kishon Vijay Abraham I]

In order to support platforms which has multiple PHY's (of same type) and
which has multiple USB controllers, a new design is adopted wherin the binding
information (between the PHY and the USB controller) should be passed to the
PHY library from platform specific file (board file). 
So added a new API to pass the binding information.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/otg/otg.c   |   37 +
 include/linux/usb/phy.h |   22 ++
 2 files changed, 59 insertions(+)

diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index a30c041..492ba2f 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -18,6 +18,7 @@
 #include 
 
 static LIST_HEAD(phy_list);
+static LIST_HEAD(phy_bind_list);
 static DEFINE_SPINLOCK(phy_lock);
 
 static struct usb_phy *__usb_find_phy(struct list_head *list,
@@ -201,6 +202,42 @@ void usb_remove_phy(struct usb_phy *x)
 }
 EXPORT_SYMBOL(usb_remove_phy);
 
+/**
+ * usb_bind_phy - bind the phy and the controller that uses the phy
+ * @dev_name: the device name of the device that will bind to the phy
+ * @index: index to specify the port number
+ * @phy_dev_name: the device name of the phy
+ *
+ * Fills the phy_bind structure with the dev_name and phy_dev_name. This will
+ * be used when the phy driver registers the phy and when the controller
+ * requests this phy.
+ *
+ * To be used by platform specific initialization code.
+ */
+struct usb_phy_bind __init *usb_bind_phy(const char *dev_name, u8 index,
+   const char *phy_dev_name)
+{
+   struct usb_phy_bind *phy_bind;
+   unsigned long flags;
+
+   phy_bind = kzalloc(sizeof(*phy_bind), GFP_KERNEL);
+   if (!phy_bind) {
+   pr_err("phy_bind(): No memory for phy_bind");
+   return ERR_PTR(-ENOMEM);
+   }
+
+   phy_bind->dev_name = dev_name;
+   phy_bind->phy_dev_name = phy_dev_name;
+   phy_bind->index = index;
+
+   spin_lock_irqsave(&phy_lock, flags);
+   list_add_tail(&phy_bind->list, &phy_bind_list);
+   spin_unlock_irqrestore(&phy_lock, flags);
+
+   return phy_bind;
+}
+EXPORT_SYMBOL_GPL(usb_bind_phy);
+
 const char *otg_state_string(enum usb_otg_state state)
 {
switch (state) {
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index a29ae1e..fbeab1a 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -106,6 +106,21 @@ struct usb_phy {
enum usb_device_speed speed);
 };
 
+/**
+ * struct usb_phy_bind - represent the binding for the phy
+ * @dev_name: the device name of the device that will bind to the phy
+ * @phy_dev_name: the device name of the phy
+ * @index: used if a single controller uses multiple phys
+ * @phy: reference to the phy
+ * @list: to maintain a linked list of the binding information
+ */
+struct usb_phy_bind {
+   const char  *dev_name;
+   const char  *phy_dev_name;
+   u8  index;
+   struct usb_phy  *phy;
+   struct list_head list;
+};
 
 /* for board-specific init logic */
 extern int usb_add_phy(struct usb_phy *, enum usb_phy_type type);
@@ -151,6 +166,8 @@ extern struct usb_phy *devm_usb_get_phy(struct device *dev,
enum usb_phy_type type);
 extern void usb_put_phy(struct usb_phy *);
 extern void devm_usb_put_phy(struct device *dev, struct usb_phy *x);
+extern struct usb_phy_bind *usb_bind_phy(const char *dev_name, u8 index,
+   const char *phy_dev_name);
 #else
 static inline struct usb_phy *usb_get_phy(enum usb_phy_type type)
 {
@@ -171,6 +188,11 @@ static inline void devm_usb_put_phy(struct device *dev, 
struct usb_phy *x)
 {
 }
 
+static inline struct usb_phy_bind *usb_bind_phy(const char *dev_name, u8 index,
+   const char *phy_dev_name)
+{
+   return NULL;
+}
 #endif
 
 static inline int
-- 
1.7.9.5

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

[PATCH v1 5/6] usb: otg: add device tree support to otg library

[Kishon Vijay Abraham I]

Added an API devm_usb_get_phy_by_phandle(), to get usb phy by passing a
device node phandle value. This function will return a pointer to
the phy on success, -EPROBE_DEFER if there is a device_node for the phandle,
but the phy has not been added, or a ERR_PTR() otherwise.

Cc: Marc Kleine-Budde 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/usb/otg/otg.c   |   77 +++
 include/linux/usb/phy.h |8 +
 2 files changed, 85 insertions(+)

diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index 1f30b22..67daf8c 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -13,7 +13,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include 
 
@@ -50,6 +52,20 @@ static struct usb_phy *__usb_find_phy_dev(struct device *dev,
return ERR_PTR(-ENODEV);
 }
 
+static struct usb_phy *__of_usb_find_phy(struct device_node *node)
+{
+   struct usb_phy  *phy;
+
+   list_for_each_entry(phy, &phy_list, head) {
+   if (node != phy->dev->of_node)
+   continue;
+
+   return phy;
+   }
+
+   return ERR_PTR(-ENODEV);
+}
+
 static void devm_usb_phy_release(struct device *dev, void *res)
 {
struct usb_phy *phy = *(struct usb_phy **)res;
@@ -125,6 +141,67 @@ err0:
 }
 EXPORT_SYMBOL(usb_get_phy);
 
+ /**
+ * devm_usb_get_phy_by_phandle - find the USB PHY by phandle
+ * @dev - device that requests this phy
+ * @phandle - name of the property holding the phy phandle value
+ * @index - the index of the phy
+ *
+ * Returns the phy driver associated with the given phandle value,
+ * after getting a refcount to it, -ENODEV if there is no such phy or
+ * -EPROBE_DEFER if there is a phandle to the phy, but the device is
+ * not yet loaded. While at that, it also associates the device with
+ * the phy using devres. On driver detach, release function is invoked
+ * on the devres data, then, devres data is freed.
+ *
+ * For use by USB host and peripheral drivers.
+ */
+struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
+   const char *phandle, u8 index)
+{
+   struct usb_phy  *phy = NULL, **ptr;
+   unsigned long   flags;
+   struct device_node *node;
+
+   if (!dev->of_node) {
+   dev_dbg(dev, "device does not have a device node entry\n");
+   return ERR_PTR(-EINVAL);
+   }
+
+   node = of_parse_phandle(dev->of_node, phandle, index);
+   if (!node) {
+   dev_dbg(dev, "failed to get %s phandle in %s node\n", phandle,
+   dev->of_node->full_name);
+   return ERR_PTR(-ENODEV);
+   }
+
+   ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
+   if (!ptr) {
+   dev_dbg(dev, "failed to allocate memory for devres\n");
+   return ERR_PTR(-ENOMEM);
+   }
+
+   spin_lock_irqsave(&phy_lock, flags);
+
+   phy = __of_usb_find_phy(node);
+   if (IS_ERR(phy) || !try_module_get(phy->dev->driver->owner)) {
+   phy = ERR_PTR(-EPROBE_DEFER);
+   devres_free(ptr);
+   goto err0;
+   }
+
+   *ptr = phy;
+   devres_add(dev, ptr);
+
+   get_device(phy->dev);
+
+err0:
+   spin_unlock_irqrestore(&phy_lock, flags);
+
+   return phy;
+}
+EXPORT_SYMBOL(devm_usb_get_phy_by_phandle);
+
 /**
  * usb_get_phy_dev - find the USB PHY
  * @dev - device that requests this phy
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 3a9ae3e..c7f5a98 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -167,6 +167,8 @@ extern struct usb_phy *devm_usb_get_phy(struct device *dev,
enum usb_phy_type type);
 extern struct usb_phy *usb_get_phy_dev(struct device *dev, u8 index);
 extern struct usb_phy *devm_usb_get_phy_dev(struct device *dev, u8 index);
+extern struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
+   const char *phandle, u8 index);
 extern void usb_put_phy(struct usb_phy *);
 extern void devm_usb_put_phy(struct device *dev, struct usb_phy *x);
 extern struct usb_phy_bind *usb_bind_phy(const char *dev_name, u8 index,
@@ -193,6 +195,12 @@ static inline struct usb_phy *devm_usb_get_phy_dev(struct 
device *dev, u8 index)
return NULL;
 }
 
+static inline struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
+   const char *phandle, u8 index)
+{
+   return NULL;
+}
+
 static inline void usb_put_phy(struct usb_phy *x)
 {
 }
-- 
1.7.9.5

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

[PATCH v1 0/6] USB: Add support for multiple PHYs of same type

[Kishon Vijay Abraham I]

This patch series adds support for adding multiple PHY's (of same type).
The binding information has to be present in the PHY library (otg.c) in
order for it to return the appropriate PHY whenever the USB controller
request for the PHY. So added a new API usb_bind_phy() to pass the binding
information. This API should be called by platform specific initialization
code.

So the binding should be done something like
usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto"); specifying the USB
controller device name, index, and the PHY device name.
I have done this binding for OMAP platforms, but it should be done for
all the platforms.

After this design, the phy can be got by passing the USB controller device
pointer and the index.

Developed this patch series on
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv
after applying "usb: musb: add driver for control module" patch series
and "ARM: dts: omap: add dt data for MUSB"

Did basic enumeration testing in omap4 panda and omap3 beagle.

Kishon Vijay Abraham I (6):
  usb: otg: Add an API to bind the USB controller and PHY
  usb: otg: utils: add facilities in phy lib to support multiple PHYs
of same type
  ARM: OMAP: USB: Add phy binding information
  drivers: usb: musb: omap: make use of the new PHY lib APIs
  usb: otg: add device tree support to otg library
  USB: MUSB: OMAP: get PHY by phandle for dt boot

 arch/arm/mach-omap2/board-2430sdp.c  |2 +
 arch/arm/mach-omap2/board-3430sdp.c  |2 +
 arch/arm/mach-omap2/board-4430sdp.c  |2 +
 arch/arm/mach-omap2/board-cm-t35.c   |2 +
 arch/arm/mach-omap2/board-devkit8000.c   |2 +
 arch/arm/mach-omap2/board-igep0020.c |2 +
 arch/arm/mach-omap2/board-ldp.c  |2 +
 arch/arm/mach-omap2/board-omap3beagle.c  |2 +
 arch/arm/mach-omap2/board-omap3evm.c |2 +
 arch/arm/mach-omap2/board-omap3logic.c   |2 +
 arch/arm/mach-omap2/board-omap3pandora.c |2 +
 arch/arm/mach-omap2/board-omap3stalker.c |2 +
 arch/arm/mach-omap2/board-omap3touchbook.c   |2 +
 arch/arm/mach-omap2/board-omap4panda.c   |2 +
 arch/arm/mach-omap2/board-overo.c|2 +
 arch/arm/mach-omap2/board-rm680.c|2 +
 arch/arm/mach-omap2/board-zoom-peripherals.c |2 +
 drivers/usb/musb/omap2430.c  |7 +-
 drivers/usb/otg/otg.c|  228 +-
 drivers/usb/otg/twl4030-usb.c|3 +-
 drivers/usb/phy/omap-usb2.c  |3 +-
 include/linux/usb/phy.h  |   43 +
 22 files changed, 314 insertions(+), 4 deletions(-)

-- 
1.7.9.5

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

Re: [RFC PATCH] gpio/omap: fix pm_runtime for IRQ functions

[Rajendra Nayak]

On Tuesday 22 January 2013 01:52 PM, Linus Walleij wrote:

In the Nomadik I had a similar situation with a GPIO used for the
ethernet IRQ. I put the GPIO number in a special board-specific
node and added this to the machine,


Thanks Linus. Are there any bindings already available on how these
special board-specific nodes can be defined in the dts files?
Are there any using some such in the mainline already?

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

Re: OMAP baseline test results for v3.8-rc4

[Russell King - ARM Linux]

On Tue, Jan 22, 2013 at 10:40:46AM +0100, Peter Korsgaard wrote:
> > "Jan" == Jan Lübbe  writes:
> 
>  Jan> On Tue, 2013-01-22 at 02:24 +, Paul Walmsley wrote:
>  >> Regarding the AM33xx test failures with appended DTBs, it would be very 
>  >> helpful if especially the TI people could try reproducing the problem.
>  >> Otherwise it's going to cause problems with merging any new AM33xx 
>  >> patches, since I won't be able to test them without additional work.  
>  >> Plus, this is something that used to work up until d01e4afd, so something 
>  >> isn't right.
> 
>  Jan> Just a guess, but there can be problems when the appended DTB
>  Jan> crosses an 1MB boundary. See this mail for details and a patch:
>  Jan> http://www.spinics.net/lists/arm-kernel/msg216898.html
> 
> True, but that doesn't seem to be the case here:
> ls -la arch/arm/boot/uImage
> -rw-r--r-- 1 peko peko 3945127 Jan 22 09:26 arch/arm/boot/uImage
> 
> E.G. far from the 1MB boundary.

Don't rely on that.  Remember, if the compressed image occupies the same
location as the decompressed kernel, the decompressor will copy the data
to a different location in RAM first - I think at RAM offset + 32K +
decompressed kernel size.

So yes, please try the patch in the link above.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP baseline test results for v3.8-rc4

[Peter Korsgaard]

> "Jan" == Jan Lübbe  writes:

 Jan> On Tue, 2013-01-22 at 02:24 +, Paul Walmsley wrote:
 >> Regarding the AM33xx test failures with appended DTBs, it would be very 
 >> helpful if especially the TI people could try reproducing the problem.
 >> Otherwise it's going to cause problems with merging any new AM33xx 
 >> patches, since I won't be able to test them without additional work.  
 >> Plus, this is something that used to work up until d01e4afd, so something 
 >> isn't right.

 Jan> Just a guess, but there can be problems when the appended DTB
 Jan> crosses an 1MB boundary. See this mail for details and a patch:
 Jan> http://www.spinics.net/lists/arm-kernel/msg216898.html

True, but that doesn't seem to be the case here:
ls -la arch/arm/boot/uImage
-rw-r--r-- 1 peko peko 3945127 Jan 22 09:26 arch/arm/boot/uImage

E.G. far from the 1MB boundary.

-- 
Bye, Peter Korsgaard
--
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 4/8] MFD: ti_am335x_tscadc: add device tree binding information

[Patil, Rachna]

Hi,

On Sun, Jan 20, 2013 at 03:58:14, Lars-Peter Clausen wrote:
> Hi,
> 
> On 01/18/2013 11:48 AM, Patil, Rachna wrote:
> > From: "Patil, Rachna" 
> > 
> > Signed-off-by: Patil, Rachna 
> > ---
> >  .../devicetree/bindings/mfd/ti_am335x_tscadc.txt   |   35 
> > 
> >  1 file changed, 35 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt 
> > b/Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt
> > new file mode 100644
> > index 000..c13c492
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/ti_am335x_tscadc.txt
> > @@ -0,0 +1,35 @@
> > +Texas Instruments - TSC / ADC multi-functional device
> > +
> > +ti_tscadc is a multi-function device with touchscreen and ADC on chip.
> > +This document describes the binding for mfd device.
> > +
> > +Required properties:
> > +- compatible: "ti,ti-tscadc"
> > +- reg: Specifies the address of MFD block
> > +- interrupts: IRQ line connected to the main SoC
> > +- interrupt-parent: The parent interrupt controller
> 
> The subnodes and their properties also need documentation.

Ok. I Will add this.

> 
> > +
> > +Optional properties:
> > +- ti,hwmods: Hardware information related to TSC/ADC MFD device
> > +
> > +Example:
> > +
> > +   tscadc: tscadc@44e0d000 {
> > +   compatible = "ti,ti-tscadc";
> > +   reg = <0x44e0d000 0x1000>;
> > +
> > +   interrupt-parent = <&intc>;
> > +   interrupts = <16>;
> > +   ti,hwmods = "adc_tsc";
> > +
> > +   tsc {
> > +   wires = <4>;
> > +   x-plate-resistance = <200>;
> > +   steps-to-configure = <5>;
> > +   wire-config = <0x00 0x11 0x22 0x33>;
> 
> Non-standard properties should have a vendor prefix.

Ok. I will fix this in the next version of the patch set.

Regards,
Rachna

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

Re: OMAP baseline test results for v3.8-rc4

[Jan Lübbe]

On Tue, 2013-01-22 at 02:24 +, Paul Walmsley wrote:
> Regarding the AM33xx test failures with appended DTBs, it would be very 
> helpful if especially the TI people could try reproducing the problem.
> Otherwise it's going to cause problems with merging any new AM33xx 
> patches, since I won't be able to test them without additional work.  
> Plus, this is something that used to work up until d01e4afd, so something 
> isn't right.

Just a guess, but there can be problems when the appended DTB crosses an
1MB boundary. See this mail for details and a patch:
http://www.spinics.net/lists/arm-kernel/msg216898.html

Regards,
Jan
-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

--
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] usb: musb: fix context save over suspend.

[Igor Grinberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It looks like Kevin has a new address:
Kevin Hilman 

On 01/21/13 23:38, NeilBrown wrote:
> On Mon, 21 Jan 2013 13:38:59 +0200 Igor Grinberg 
> wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
> 
>> Hi Neil,
> 
>> On 01/21/13 11:28, NeilBrown wrote:
>>>
>>>
>>> The standard suspend sequence involves runtime_resuming
>>> devices before suspending the system.
>>> So just saving context in runtime_suspend and restoring it
>>> in runtime resume isn't enough.  We  must also save in "suspend"
>>> and restore in "resume".
>>>
>>> Without this patch, and OMAP3 system with off_mode enabled will find
>>> the musb port non-functional after suspend/resume.  With the patch it
>>> works perfectly.
> 
>> Hmmm... Some time ago, this has been removed in
>> 5d193ce8 (usb: musb: PM: fix context save/restore in suspend/resume path)
> 
>> Am I missing something? Or things changed and now this patch is correct?
> 
> Hi Igor,
>  thanks for alerting me to that patch  does anyone else get the feeling
>  that power management to too complex to be understood by a mere human?
> 
>  That commit (5d193ce8) suggests that the musb-hdrc device is an
>  'omap_device', or maybe has a PM domain set to something else.
>  However it isn't/doesn't.  dev->pm_domain is NULL.  So no PM domain layer
>  will ever call the musb_core musb_runtime_suspend/resume.
> 
>  The parent device - musb-omap2430 - is an omap device, does have pm_domain
>  set, and does have its omap2430_runtime_suspend/resume called for system
>  suspend and so the context for that device is saved and restored.
>  However that doesn't help the context for musb-hdrc.
> 
>  Whether musb ever was an omap_device is beyond my archaeological skills to
>  determine.
> 
>  Kevin:  Was musb-hdrc ever a device with a pm_domain? or was it only ever
>  the various possible parents that had domains?
>  Are you able to defend your earlier patch in today's kernel?  It
>  certainly causes my device not to work properly.
> 
> Thanks,
> NeilBrown
> 
> 
> 
> 
>>>
>>> Signed-off-by: NeilBrown 
>>>
>>> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
>>> index fd34867..b6ccc02 100644
>>> --- a/drivers/usb/musb/musb_core.c
>>> +++ b/drivers/usb/musb/musb_core.c
>>> @@ -2225,6 +2225,7 @@ static int musb_suspend(struct device *dev)
>>> }
>>>  
>>> spin_unlock_irqrestore(&musb->lock, flags);
>>> +   musb_save_context(musb);
>>> return 0;
>>>  }
>>>  
>>> @@ -2234,6 +2235,8 @@ static int musb_resume_noirq(struct device *dev)
>>>  * unless for some reason the whole soc powered down or the USB
>>>  * module got reset through the PSC (vs just being disabled).
>>>  */
>>> +   struct musb *musb = dev_to_musb(dev);
>>> +   musb_restore_context(musb);
>>> return 0;
>>>  }
>>>  
> 
>> - -- 
>> Regards,
>> Igor.
>> 


- -- 
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQ/lgWAAoJEBDE8YO64EfacIAP/3nyXjs8QQpcD6RcNuRSLp3O
veKU2grzsUOL/Eu/8TQMM7WDz5n8YlycQ6/THNGGYojjOlEimDC02wbsI4gc5j41
QC1/XGf62Nlxv6CzORzkGkUoKXtVWzgMYKddWKPEwsXMKPun/LH4ZGDp+7Rkfcmu
U0k7LM1Pv487iG9pF3Bq5BPYeMxyxyFJC0PiQEK1ZE65RKWbCvInibc7p1bvZ+XX
JQxf8Qx1p/kBhqWc6LLpcHT5Z3B/F+3rxEhvf8lSu5fdRPHFffcmuX7bIbC/GlTe
e6mODA114mtn5YbaKCmnYExvJcpz4Nziy+8fGLJ56aAyeKI1wsOJzhWDpSKwQiIF
CVtYulk5iIfaeUA4sAzvRqEu7dJuaVgm6mEeGHQjebPastYhK7vHjiEOJJ2+LQrs
698A9wMLckp4AQ75HiwXRgi5N0W528gD8piNoIA9Sh1LwyytIa5Wg7uYw14UjtLJ
QIerm0v6Ay+8FbVfmpm9k0v3HkYfv0ZVTSdtIXVAE30+WKIBTn0yszxWYo6JZtvj
p0NEFUNVuR3C9k/xyzkcqwJh8Q6DrleWJeHWL59xgWWKzfeDKjU/DMOuWmuVEkTO
aRdAlW32VDtUeWlWz3Jz3IOWZRJQKCW2o97n/MDyxwMoRiMWcHxYw6jti6se9S7a
IGZeEMCcf39fnH5o7i2q
=nwGe
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP baseline test results for v3.8-rc4

[Peter Korsgaard]

> "Paul" == Paul Walmsley  writes:

 Paul> Hi guys,

 Paul> Regarding the AM33xx test failures with appended DTBs, it would
 Paul> be very helpful if especially the TI people could try reproducing
 Paul> the problem.  Otherwise it's going to cause problems with merging
 Paul> any new AM33xx patches, since I won't be able to test them
 Paul> without additional work.  Plus, this is something that used to
 Paul> work up until d01e4afd, so something isn't right.

 Paul> You'll need to use the bootloader that TI originally shipped with
 Paul> the BeagleBones:

 Paul> U-Boot 2011.09-9-gcf6e04d (Mar 08 2012 - 17:15:43)

FYI, my beaglebone came with a slightly different U-Boot:

U-Boot 2011.09-0-gf63b270-dirty (Nov 14 2011 - 10:37:14)

But I have the same behaviour. Recent kernels work with a modern U-Boot,
but not the original. The build I'm doing is very similar to yours:

git describe
v3.8-rc4-71-g9a92841

make ARCH=arm CROSS_COMPILE=arm-linux- omap2plus_defconfig
echo CONFIG_ARM_APPENDED_DTB=y >> .config
echo CONFIG_ARM_ATAG_DTB_COMPAT=y >> .config
yes ''| make ARCH=arm CROSS_COMPILE=arm-linux- oldconfig
make ARCH=arm CROSS_COMPILE=arm-linux-
cat arch/arm/boot/dts/am335x-bone.dtb >> arch/arm/boot/zImage
make ARCH=arm CROSS_COMPILE=arm-linux- uImage

# old u-boot (ethernet not stable here, so load from sd)

U-Boot SPL 2011.09-0-gf63b270-dirty (Nov 14 2011 - 10:37:14)
Texas Instruments Revision detection unimplemented
No AC power, disabling frequency switch
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img


U-Boot 2011.09-0-gf63b270-dirty (Nov 14 2011 - 10:37:14)

I2C:   ready
DRAM:  256 MiB
No daughter card present
NAND:  HW ECC Hamming Code selected
nand_get_flash_type: unknown NAND device: Manufacturer ID: 0x10, Chip ID: 0x10
No NAND device found!!!
0 MiB
MMC:   OMAP SD/MMC: 0
*** Warning - readenv() failed, using default environment

Net:   cpsw
Hit any key to stop autoboot:  0
U-Boot# mmc rescan
U-Boot# fatload mmc 0:1 0x8020 uImage.new
reading uImage.new

3945127 bytes read
U-Boot# setenv bootargs console=$console
U-Boot# bootm 0x8020
## Booting kernel from Legacy Image at 8020 ...
   Image Name:   Linux-3.8.0-rc4-00071-g9a92841
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3945063 Bytes = 3.8 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

And it hangs. With a reasonably modern U-Boot it works:

U-Boot SPL 2012.10 (Oct 29 2012 - 23:39:02)
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img


U-Boot 2012.10 (Oct 29 2012 - 23:39:02)

I2C:   ready
DRAM:  256 MiB
WARNING: Caches not enabled
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

Net:   cpsw
Hit any key to stop autoboot:  0
U-Boot# dhcp
link up on port 0, speed 100, full duplex
BOOTP broadcast 1
DHCP client bound to address 172.16.1.2
Using cpsw device
TFTP from server 172.16.1.1; our IP address is 172.16.1.2
Filename 'uImage'.
Load address: 0x8020
Loading: #
 #
 #
 #
 #
done
Bytes transferred = 3945127 (3c32a7 hex)
U-Boot# setenv bootargs console=$console
U-Boot# bootm
## Booting kernel from Legacy Image at 8020 ...
   Image Name:   Linux-3.8.0-rc4-00071-g9a92841
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3945063 Bytes = 3.8 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.8.0-rc4-00071-g9a92841 (peko@dell) (gcc version 3
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instructie
[0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335e
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] AM335X ES1.0 (neon )
...

For the failing case, __log_buf doesn't contain anything sensible so I
guess it crashes early:

grep __log_buf System.map
c07cc450 b __log_buf
U-Boot# md 807cc450
807cc450: e5749fbf ef220eff 3df957df acebffbd..t..."..W.=
807cc460: 61df 7e93c5ef ddbafdfd bb2ac2fd...a...~..*.
807cc470: 7ff1 f7fafd7f 717ddf7f 3feecfbc..}q...?
807cc480: bddb573d beeaba9b c57f7b99 f77dfbfe=W...{}.
807cc490: 6b7dde97 ebffcfaf fdf62df5 77e5f7bb..}k.-.w
807cc4a0: 5fdffdf5 7bc2d8be 7d977ddd feafafff..._...{.}.}
807cc4b0: f7429df5 76e2fd6d dedffd3d cf6769ff..B.m..v=ig.
807cc4c0: fb5644dd bdcf3a69 ffbfffd9 befff9ae.DV.i:..
807cc4d0: f7537fd7 feafe2f2 f37c7c2f fe5ffded 

Re: [PATCH v2 3/3] arm: omap2: gpmc: add DT bindings for OneNAND

[Daniel Mack]

Hi Tony, Mark, Ezequiel,

Tony Lindgren  wrote:

>* Ezequiel Garcia  [130121 09:00]:
>> Hi Mark,
>> 
>> On Mon, Jan 21, 2013 at 9:30 AM, Mark Rutland 
>wrote:
>> > [...]
>> >
>> >> diff --git a/arch/arm/mach-omap2/gpmc.c
>b/arch/arm/mach-omap2/gpmc.c
>> >> index 01ce462..f7de9eb 100644
>> >> --- a/arch/arm/mach-omap2/gpmc.c
>> >> +++ b/arch/arm/mach-omap2/gpmc.c
>> >> @@ -39,6 +39,7 @@
>> >>  #include "omap_device.h"
>> >>  #include "gpmc.h"
>> >>  #include "gpmc-nand.h"
>> >> +#include "gpmc-onenand.h"
>> >>
>> >>  #define  DEVICE_NAME "omap-gpmc"
>> >>
>> >> @@ -1259,6 +1260,43 @@ static int gpmc_probe_nand_child(struct
>platform_device *pdev,
>> >>  }
>> >>  #endif
>> >>
>> >> +#ifdef CONFIG_MTD_ONENAND
>> >> +static int gpmc_probe_onenand_child(struct platform_device *pdev,
>> >> +  struct device_node *child)
>> >> +{
>> >> + u32 val;
>> >> + struct omap_onenand_platform_data *gpmc_onenand_data;
>> >> +
>> >> + if (of_property_read_u32(child, "reg", &val) < 0) {
>> >> + dev_err(&pdev->dev, "%s has no 'reg' property\n",
>> >> + child->full_name);
>> >> + return -ENODEV;
>> >> + }
>> >> +
>> >> + gpmc_onenand_data = devm_kzalloc(&pdev->dev,
>sizeof(*gpmc_onenand_data),
>> >> +  GFP_KERNEL);
>> >> + if (!gpmc_onenand_data)
>> >> + return -ENOMEM;
>> >> +
>> >> + gpmc_onenand_data->cs = val;
>> >> + gpmc_onenand_data->of_node = child;
>> >> + gpmc_onenand_data->dma_channel = -1;
>> >> +
>> >> + if (!of_property_read_u32(child, "dma-channel", &val))
>> >> + gpmc_onenand_data->dma_channel = val;
>> >> +
>> >> + gpmc_onenand_init(gpmc_onenand_data);
>> >> +
>> >> + return 0;
>> >> +}
>> >> +#else
>> >> +static int gpmc_probe_onenand_child(struct platform_device *pdev,
>> >> + struct device_node *child)
>> >> +{
>> >> + return 0;
>> >> +}
>> >> +#endif
>> >> +
>> >>  static int gpmc_probe_dt(struct platform_device *pdev)
>> >>  {
>> >>   int ret;
>> >> @@ -1276,6 +1314,12 @@ static int gpmc_probe_dt(struct
>platform_device *pdev)
>> >>   return ret;
>> >>   }
>> >>
>> >
>> > This doesn't look right to me:
>> >
>> >> + for_each_node_by_name(child, "onenand") {
>> >> + ret = gpmc_probe_onenand_child(pdev, child);
>> >> + of_node_put(child);
>> >> + if (ret < 0)
>> >> + return ret;
>> >> + }
>> >
>> > for_each_node_by_name automatically calls of_node_put on each node
>once passed,
>> > and as far as I can tell, gpmc_probe_onenand_child doesn't do
>anything that'd
>> > increment a node's refcount.
>> >
>> > As far as I can see, you only need the of_node_put in the error
>case:
>> >
>> > for_each_node_by_name(child, "onenand") {
>> > ret = gpmc_probe_onenand_child(pdev, child);
>> > if (ret < 0) {
>> > of_node_put(child);
>> > return ret;
>> > }
>> > }
>> >
>> > Have I missed something here?
>> >
>> 
>> Mmm... perhaps I've overlooked that code.
>> 
>> After some digging through source and reading for_each_node_by_name()
>> it seems to me you're right.
>> 
>> @Daniel: It seems this would also apply to the NAND binding.
>> What do you think?
>
>Would prefer this done as a fix against the omap-for-v3.9/gpmc
>branch before we apply Ezequiel's patches.

I'm currently far away from my computer and can't prepare a patch for this, 
sorry. But I think you are right, so please just submit a patch for that, 
anyone :-)

Best regards,
Daniel


--
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