On Fri, Jun 22, 2012 at 06:45:41PM +0530, Kishon Vijay Abraham I wrote:
> Adds a new driver _ocp2scp_.
That's not what you called this driver in the patch below :(
> This driver takes the responsibility of creating
> all the devices that is connected to OCP2SCP. In the case of OMAP4, USB2PHY
> is
Dear Grant Likely,
> On Thu, Jul 28, 2011 at 09:22:59PM +0200, manu wrote:
> > Dear Grant, Shawn,
> > I don't this patch is required as m25p** serial flashes are
> > supported already with generic OF/SPI and OF/MTD schemes.
> > I have successfully used it myself on an unmodified 2.6.36.3 vanilla
>
From: David Daney
Add a driver for BCM8706 and BCM8727 devices. These are a 10Gig PHYs
which use MII_ADDR_C45 addressing. They are always 10G full duplex, so
there is no autonegotiation. All we do is report link state and send
interrupts when it changes.
If the PHY has a device tree of_node a
From: David Daney
The IEEE802.3 clause 45 MDIO bus protocol allows for directly
addressing PHY registers using a 21 bit address, and is used by many
10G Ethernet PHYS. Already existing is the ability of MDIO bus
drivers to use clause 45, with the MII_ADDR_C45 flag. Here we add
struct phy_c45_de
From: David Daney
Allow PHY drivers to supply their own device matching function
(match_phy_device()), or to be matched OF compatible properties.
PHYs following IEEE802.3 clause 45 have more than one device
identifier constants, which breaks the default device matching code.
Other 10G PHYs don't
From: David Daney
Define two new "compatible" values for Ethernet
PHYs. "ethernet-phy-ieee802.3-c22" and "ethernet-phy-ieee802.3-c45"
are used to indicate a PHY uses the corresponding protocol.
If a PHY is "compatible" with "ethernet-phy-ieee802.3-c45", we
indicate this so that get_phy_device()
From: David Daney
The existing PHY driver infrastructure supports IEEE 802.3 Clause 22
PHYs used with 10/100/1000MB Ethernet. For 10G Ethernet, many PHYs
use 802.3 Clause 45. These patches attempt to add core support for
this as well as a driver for BCM87XX 10G PHY devices.
This is reworked fr
Before this goes much further... one fairly obvious and important point
must be made.
You're designing an API here. You're designing it *WITHOUT* involving
the two most important people in its design that there are. The
DMA engine maintainers. Is this how we go about designing APIs - behind
mai
Hi Arnd,
On 06/14/2012 06:48 AM, Arnd Bergmann wrote:
[snip]
> This would let us handle the following cases very easily:
>
> 1. one read-write channel
>
> dmas = <&dmac 0x3 match>;
>
> 2. a choice of two read-write channels:
>
> dmas = <&dmacA 0x3 matchA>, <&dmacB 0x3 matchB>;
>
On Friday 22 June 2012, Bjorn Helgaas wrote:
>
> On Fri, Jun 22, 2012 at 10:53 AM, Arnd Bergmann wrote:
> > On Friday 22 June 2012, Bjorn Helgaas wrote:
> >> The requirement (if there is one) isn't anything related to PC-ness.
> >> I just don't understand how things can actually work if two host
On 06/22/2012 02:39 AM, Tony Lindgren wrote:
> Hi,
>
> * Stephen Warren [120621 15:17]:
>> On 06/19/2012 07:56 AM, Tony Lindgren wrote:
>>> +
>>> +- pinctrl-single,pinconf-mask : mask of allowed pinconf bits in the
>>> + pinmux register; this gets combined with pinconf mask but is a separate
>>>
On 06/22/2012 11:00 AM, Stephen Warren wrote:
> On 06/22/2012 05:00 AM, Thierry Reding wrote:
> ...
>> Stephen: can you try to find out whether the Tegra PCIe controller
>> indeed implements ECAM, or if this scheme is actually just a
>> proprietary variant?
>
> Sure. I have added this request to
On Friday 22 June 2012, Uwe Kleine-König wrote:
> On Thu, Jun 07, 2012 at 12:20:14PM +0200, Uwe Kleine-König wrote:
> > Drivers should never need to modify the data of a device id. So it can
> > be const which in turn allows more consts in the driver.
> >
> > Signed-off-by: Uwe Kleine-König
> > -
On Friday 22 June 2012, Arnd Bergmann wrote:
> The part that is specific to PCs is that they don't have PCI domains
> normally.
Scratch that, PCs have moved on beyond that long ago, I just wasn't
aware that they also do that now. That was only true before mmconfig.
Arnd
__
On Fri, Jun 22, 2012 at 10:53 AM, Arnd Bergmann wrote:
> On Friday 22 June 2012, Bjorn Helgaas wrote:
>> The requirement (if there is one) isn't anything related to PC-ness.
>> I just don't understand how things can actually work if two host
>> bridges both claim the same bus number. If we do a c
On 6/20/2012 8:47 PM, Thierry Reding wrote:
On Tue, Jun 19, 2012 at 11:31:39AM -1000, Mitch Bradley wrote:
On 6/19/2012 3:30 AM, Thierry Reding wrote:
On Fri, Jun 15, 2012 at 08:12:36AM +0200, Thierry Reding wrote:
On Thu, Jun 14, 2012 at 01:50:56PM -0600, Stephen Warren wrote:
On 06/14/2012
On 06/22/2012 05:00 AM, Thierry Reding wrote:
...
> Stephen: can you try to find out whether the Tegra PCIe controller
> indeed implements ECAM, or if this scheme is actually just a
> proprietary variant?
Sure. I have added this request to the bug I filed requesting more
complete PCIe host docume
On Friday 22 June 2012, Bjorn Helgaas wrote:
> The requirement (if there is one) isn't anything related to PC-ness.
> I just don't understand how things can actually work if two host
> bridges both claim the same bus number. If we do a config read to
> that bus, both bridges should claim it and tu
On Fri, Jun 22, 2012 at 7:03 AM, Arnd Bergmann wrote:
> On Friday 22 June 2012, Thierry Reding wrote:
>> On Fri, Jun 22, 2012 at 05:46:52AM -0600, Bjorn Helgaas wrote:
>> > On Fri, Jun 22, 2012 at 5:00 AM, Thierry Reding
>> > wrote:
>> > >> Is the bus number aperture included somewhere? How do w
On Friday 22 June 2012, Thierry Reding wrote:
> Actually this is from of_translate_address(). The calling sequence looks
> like this:
>
> of_address_to_resource()
> __of_address_to_resource()
> of_translate_address()
> __of_translate_address()
>
On 06/21/2012 12:47 AM, Thierry Reding wrote:
...
> Everybody seems to be happy with this approach, so I'll give it a
> shot. There is one thing I'm still unsure about, though. What if
> somebody uses the above scheme and maps the registers to the wrong
> port. The same goes for the nvidia,ctrl-off
On Fri, Jun 22, 2012 at 01:48:39PM +, Arnd Bergmann wrote:
> On Friday 22 June 2012, Thierry Reding wrote:
> > > It seems like this isn't working properly. For some reason both the reg
> > > property of pci@0 and pci@1 are translated to the same parent address
> > > 0x8000. I'll have to inv
On Friday 22 June 2012, Thierry Reding wrote:
> > It seems like this isn't working properly. For some reason both the reg
> > property of pci@0 and pci@1 are translated to the same parent address
> > 0x8000. I'll have to investigate where exactly this goes wrong.
>
> So it turns out that while
All the PHY configuration other than VBUS, ID GND and OTG SRP are removed
from twl6030. The phy configurations are taken care by the dedicated
usb2 phy driver. So twl6030 is made as comparator driver for VBUS and
ID detection.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/musb/omap2430.c
Added device tree support for omap musb driver and updated the
Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 32 +
drivers/usb/musb/omap2430.c| 48
Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-.dts file.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap3-beagle.dts |6 ++
arch/arm/boot/dts/omap3-evm.dts|6 ++
arch/arm/boot/dts/omap3.dtsi
All phy related programming like enabling/disabling the clocks, powering
on/off the phy is taken care of by this driver. It is also used for OTG
related functionality like srp.
This also includes device tree support for usb2 phy driver and
the documentation with device tree binding information is
All the unnessary functions in omap-phy-internal is removed.
These functionality are now handled by omap-usb2 phy driver.
Cc: Felipe Balbi
Signed-off-by: Kishon Vijay Abraham I
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/omap_phy_internal.c | 138 ---
arch/arm/
Add device tree support for twl6030 usb driver.
Update the Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I
---
.../devicetree/bindings/usb/twl-usb.txt| 18 +
drivers/usb/otg/twl6030-usb.c | 41 +---
Add device tree support for twl6030 usb driver.
Update the Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I
---
.../devicetree/bindings/usb/twl-usb.txt| 19 ++
drivers/usb/otg/twl4030-usb.c | 26 +++
Add twl4030-usb data node in twl4030 device tree file.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/twl4030.dtsi | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 22f4
Add omap-usb2 data node in omap4 device tree file.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap4.dtsi |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 9082191..e670394 100644
--- a/ar
Add twl6030-usb data node in twl6030 device tree file
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/twl6030.dtsi |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 3b2f351..6526366 100
This patch series adds device tree support for MUSB and device
tree support for all the related modules to get MUSB working in
OMAP platform.
A new omap-usb2 phy driver has been added (with only dt suppport)
to perform phy configurations. Previously this configuration was
performed by twl6030, usi
This patch series is done as a preparatory step for adding phy drivers
for dwc3 and musb.
This series adds a new driver for ocp2scp (only dt) to which phy
drivers are connected.
Since currently there is no generic way to create a child device along
with doing a pm_runtime_enable (the exact requir
On Fri, Jun 22, 2012 at 01:04:03PM +0200, Thierry Reding wrote:
> On Tue, Jun 19, 2012 at 11:31:39AM -1000, Mitch Bradley wrote:
> > On 6/19/2012 3:30 AM, Thierry Reding wrote:
> > >On Fri, Jun 15, 2012 at 08:12:36AM +0200, Thierry Reding wrote:
> > >>On Thu, Jun 14, 2012 at 01:50:56PM -0600, Steph
Adds a new driver _ocp2scp_. This driver takes the responsibility of creating
all the devices that is connected to OCP2SCP. In the case of OMAP4, USB2PHY
is connected to ocp2scp.
This also includes device tree support for ocp2scp driver and
the documentation with device tree binding information is
Add ocp2scp data node in omap4 device tree file.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap4.dtsi |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d2cb392..9082191 100644
--- a/a
On Friday 22 June 2012, Thierry Reding wrote:
> On Fri, Jun 22, 2012 at 05:46:52AM -0600, Bjorn Helgaas wrote:
> > On Fri, Jun 22, 2012 at 5:00 AM, Thierry Reding
> > wrote:
> > >> Is the bus number aperture included somewhere? How do we know what
> > >> bus numbers are available for allocation u
On Fri, Jun 22, 2012 at 05:46:52AM -0600, Bjorn Helgaas wrote:
> On Fri, Jun 22, 2012 at 5:00 AM, Thierry Reding
> wrote:
> > On Fri, Jun 22, 2012 at 04:18:05AM -0600, Bjorn Helgaas wrote:
> >> On Thu, Jun 21, 2012 at 12:47 AM, Thierry Reding
> >> wrote:
> >> > On Tue, Jun 19, 2012 at 11:31:39AM
On Fri, Jun 22, 2012 at 5:00 AM, Thierry Reding
wrote:
> On Fri, Jun 22, 2012 at 04:18:05AM -0600, Bjorn Helgaas wrote:
>> On Thu, Jun 21, 2012 at 12:47 AM, Thierry Reding
>> wrote:
>> > On Tue, Jun 19, 2012 at 11:31:39AM -1000, Mitch Bradley wrote:
>>
>> >> Version A - 3 address cells: In this
On Tue, Jun 19, 2012 at 11:31:39AM -1000, Mitch Bradley wrote:
> On 6/19/2012 3:30 AM, Thierry Reding wrote:
> >On Fri, Jun 15, 2012 at 08:12:36AM +0200, Thierry Reding wrote:
> >>On Thu, Jun 14, 2012 at 01:50:56PM -0600, Stephen Warren wrote:
> >>>On 06/14/2012 01:29 PM, Thierry Reding wrote:
> >>
On Fri, Jun 22, 2012 at 04:18:05AM -0600, Bjorn Helgaas wrote:
> On Thu, Jun 21, 2012 at 12:47 AM, Thierry Reding
> wrote:
> > On Tue, Jun 19, 2012 at 11:31:39AM -1000, Mitch Bradley wrote:
>
> >> Version A - 3 address cells: In this version, the intermediate
> >> address space has 3 cells: por
On Thu, Jun 21, 2012 at 12:47 AM, Thierry Reding
wrote:
> On Tue, Jun 19, 2012 at 11:31:39AM -1000, Mitch Bradley wrote:
>> Version A - 3 address cells: In this version, the intermediate
>> address space has 3 cells: port#, address type, offset. Address
>> type is
>> 0 : root port
>> 1 : c
Hi Stephen,
The PWM subsystem patches have gone through a number of versions now and
all outstanding issues have been resolved. I believe that the subsystem
is ready for broader testing in linux-next. If all goes well I plan to
submit it to Linus during the 3.6 merge window.
I am not aware of any
On Fri, Jun 22, 2012 at 10:59:09AM +0200, Thierry Reding wrote:
> On Fri, Jun 22, 2012 at 09:42:29AM +0100, Mark Brown wrote:
> > We're talking about consumers here, not the regulator driver finding its
> > own regulators.
> No we're not. of_regulator_match() isn't used by consumers but by
> regu
On Fri, Jun 22, 2012 at 09:42:29AM +0100, Mark Brown wrote:
> On Fri, Jun 22, 2012 at 08:13:14AM +0200, Thierry Reding wrote:
> > On Wed, Jun 20, 2012 at 08:46:10PM +0100, Mark Brown wrote:
>
> > > As well as being able to refer to the object from within the device tree
> > > we also need to be ab
On Fri, Jun 22, 2012 at 08:13:14AM +0200, Thierry Reding wrote:
> On Wed, Jun 20, 2012 at 08:46:10PM +0100, Mark Brown wrote:
> > As well as being able to refer to the object from within the device tree
> > we also need to be able to tell what the object represents - we have a
> > bunch of regulat
On Tue, Jun 19, 2012 at 11:31:39AM -1000, Mitch Bradley wrote:
> On 6/19/2012 3:30 AM, Thierry Reding wrote:
> >On Fri, Jun 15, 2012 at 08:12:36AM +0200, Thierry Reding wrote:
> >>On Thu, Jun 14, 2012 at 01:50:56PM -0600, Stephen Warren wrote:
> >>>On 06/14/2012 01:29 PM, Thierry Reding wrote:
> >>
On Thu, Jun 21, 2012 at 02:17:32PM -0600, Stephen Warren wrote:
> On 06/11/2012 09:05 AM, Thierry Reding wrote:
> > Device tree support for the TPS6586x PMU used on Harmony has recently
> > been added. This commit adds the required device tree nodes to probe the
> > PMU from the device tree.
>
> >
Hi,
* Stephen Warren [120621 15:17]:
> On 06/19/2012 07:56 AM, Tony Lindgren wrote:
> > +
> > +- pinctrl-single,pinconf-mask : mask of allowed pinconf bits in the
> > + pinmux register; this gets combined with pinconf mask but is a separate
> > + mask to allow the option of setting pinconf sepa
On Wed, Jun 20, 2012 at 08:46:10PM +0100, Mark Brown wrote:
> On Wed, Jun 20, 2012 at 07:24:09PM +, Arnd Bergmann wrote:
>
> > 1. What is it that the new property can express that cannot already
> > be expressed by using the phandle.
>
> As well as being able to refer to the object from withi
52 matches
Mail list logo
