* [PATCH 1/2] DT: net: davinci_emac: "ti,davinci-rmii-en" property is actually optional
From: Sergei Shtylyov @ 2014-01-27 23:47 UTC (permalink / raw)
To: netdev, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
rob, devicetree
Cc: linux-doc, davinci-linux-open-source
Though described as required, the "ti,davinci-rmii-en" property for the DaVinci
EMAC binding seems actually optional, as the driver should happily work without
it; the property is not specified either in the example device node or in the
actual EMAC device node for DA850 device tree, only AM3517 one.
While at it, document the property better...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Actually I think this property should have been boolean...
Documentation/devicetree/bindings/net/davinci_emac.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: net/Documentation/devicetree/bindings/net/davinci_emac.txt
===================================================================
--- net.orig/Documentation/devicetree/bindings/net/davinci_emac.txt
+++ net/Documentation/devicetree/bindings/net/davinci_emac.txt
@@ -10,7 +10,6 @@ Required properties:
- ti,davinci-ctrl-mod-reg-offset: offset to control module register
- ti,davinci-ctrl-ram-offset: offset to control module ram
- ti,davinci-ctrl-ram-size: size of control module ram
-- ti,davinci-rmii-en: use RMII
- ti,davinci-no-bd-ram: has the emac controller BD RAM
- interrupts: interrupt mapping for the davinci emac interrupts sources:
4 sources: <Receive Threshold Interrupt
@@ -22,6 +21,7 @@ Optional properties:
- phy-handle: Contains a phandle to an Ethernet PHY.
If absent, davinci_emac driver defaults to 100/FULL.
- local-mac-address : 6 bytes, mac address
+- ti,davinci-rmii-en: 1 byte, 1 means use RMII
Example (enbw_cmc board):
eth0: emac@1e20000 {
^ permalink raw reply
* [PATCH 0/2] DT: net: davinci_emac: couple more properties actually optional
From: Sergei Shtylyov @ 2014-01-27 23:45 UTC (permalink / raw)
To: netdev, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
rob, devicetree
Cc: linux-doc, davinci-linux-open-source
Hello.
Though described as required, couple more properties in the DaVinci EMAC
binding are actually optional, as the driver will happily function without them.
The patchset is against DaveM's 'net.git' tree this time.
[1/2] DT: net: davinci_emac: "ti,davinci-rmii-en" property is actually optional
[2/2] DT: net: davinci_emac: "ti,davinci-no-bd-ram" property is actually optional
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 3/3] net: via-rhine: add OF bus binding
From: Ben Hutchings @ 2014-01-27 23:40 UTC (permalink / raw)
To: Alexey Charkov
Cc: netdev, Tony Prisk, devicetree, Roger Luethi,
linux-kernel@vger.kernel.org
In-Reply-To: <CABjd4Yz2Kfed_qBfSAEXoAcVxfsmhTBA-83YJ9_iSwPZ+r1qYQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]
On Mon, 2014-01-27 at 19:34 +0400, Alexey Charkov wrote:
> 2014/1/27 Ben Hutchings <ben@decadent.org.uk>:
> > On Mon, 2014-01-27 at 15:51 +0400, Alexey Charkov wrote:
> >> This should make the driver usable with VIA/WonderMedia ARM-based
> >> Systems-on-Chip integrated Rhine III adapters. Note that these
> >> are always in MMIO mode, and don't have any known EEPROM.
> > [...]
> >> --- a/drivers/net/ethernet/via/Kconfig
> >> +++ b/drivers/net/ethernet/via/Kconfig
> >> @@ -19,7 +19,7 @@ if NET_VENDOR_VIA
> >>
> >> config VIA_RHINE
> >> tristate "VIA Rhine support"
> >> - depends on PCI
> >> + depends on (PCI || USE_OF)
> >> select CRC32
> >> select MII
> >> ---help---
> >
> > This seems like the right thing to do, but it means you need to add
> > #ifdef CONFIG_PCI and #ifdef CONFIG_USE_OF around the driver structures
> > and related functions.
>
> Frankly, I would like to avoid that if possible (as pointed out in the
> cover email), as I believe we would get a cleaner driver without
> #ifdef. This is also the way it was done in via-velocity, and it works
> just fine.
OK, I'm surprised that all the PCI functions have dummy definitions.
> > You should compile-test in configurations that have just one of those
> > dependencies enabled.
>
> This has been compile-tested and runtime-tested in OF-only
> configuration on WM8950, and Roger also tested it in PCI-only
> configuration, so it seems to work fine.
[...]
Good, then I have no objection.
Ben.
--
Ben Hutchings
If at first you don't succeed, you're doing about average.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [RFC PATCH V3 0/4] APM X-Gene PCIe controller
From: Tanmay Inamdar @ 2014-01-27 22:58 UTC (permalink / raw)
To: Dann Frazier
Cc: Bjorn Helgaas, Arnd Bergmann, Jason Gunthorpe, Grant Likely,
Rob Herring, Catalin Marinas, Rob Landley, linux-pci, devicetree,
linux-arm-kernel@lists.infradead.org, linux-doc,
linux-kernel@vger.kernel.org, patches, Jon Masters
In-Reply-To: <CALdTtnsEo74UeYgoQ0DF7=LN074b_0bL0vg6Bxs02B9nDkRTNA@mail.gmail.com>
On Sat, Jan 25, 2014 at 8:09 AM, Dann Frazier
<dann.frazier@canonical.com> wrote:
> On Fri, Jan 24, 2014 at 2:32 PM, Tanmay Inamdar <tinamdar@apm.com> wrote:
>> This patch adds support for AppliedMicro X-Gene PCIe host controller. The
>> driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint
>> cards.
>>
>> X-Gene PCIe controller driver has depedency on the pcie arch support for
>> arm64. The arm64 pcie arch support is not yet part of mainline Linux kernel
>> and approach for arch support is under discussion with arm64 maintainers.
>> The reference patch can be found here --> https://lkml.org/lkml/2013/10/23/244
>
> The reference patch looks corrupted (pcibios.c has no includes, etc),
> would you mind reposting?
Yes. You are right. I will re-post the patch.
>
> -dann
>
>> If someone wishes to test PCIe on X-Gene, arch support patch must be applied
>> before the patches in this patch set.
>>
>> changes since V2:
>> 1. redefined each PCI port in different PCI domain correctly.
>> 2. removed setup_lane and setup_link functions from driver.
>> 3. removed scan_bus wrapper and set_primary_bus hack.
>> 4. added pci_ioremap_io for io resources.
>>
>> changes since V1:
>> 1. added PCI domain support
>> 2. reading cpu and pci addresses from device tree to configure regions.
>> 3. got rid of unnecessary wrappers for readl and writel.
>> 4. got rid of endpoint configuration code.
>> 5. added 'dma-ranges' property support to read inbound region configuration.
>> 6. renamed host driver file to 'pci-xgene.c' from 'pcie-xgene.c'
>> 7. dropped 'clock-names' property from bindings
>> 8. added comments whereever requested.
>>
>> Tanmay Inamdar (4):
>> pci: APM X-Gene PCIe controller driver
>> arm64: dts: APM X-Gene PCIe device tree nodes
>> dt-bindings: pci: xgene pcie device tree bindings
>> MAINTAINERS: entry for APM X-Gene PCIe host driver
>>
>> .../devicetree/bindings/pci/xgene-pci.txt | 52 ++
>> MAINTAINERS | 7 +
>> arch/arm64/boot/dts/apm-mustang.dts | 8 +
>> arch/arm64/boot/dts/apm-storm.dtsi | 155 ++++
>> drivers/pci/host/Kconfig | 10 +
>> drivers/pci/host/Makefile | 1 +
>> drivers/pci/host/pci-xgene.c | 784 ++++++++++++++++++++
>> 7 files changed, 1017 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pci/xgene-pci.txt
>> create mode 100644 drivers/pci/host/pci-xgene.c
>>
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] DT: net: davinci_emac: "ti,davinci-rmii-en" property is actually optional
From: Florian Fainelli @ 2014-01-27 22:57 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: netdev, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Rob Landley, devicetree@vger.kernel.org,
linux-doc@vger.kernel.org, davinci-linux-open-source
In-Reply-To: <201401280247.42415.sergei.shtylyov@cogentembedded.com>
2014-01-27 Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>:
> Though described as required, the "ti,davinci-rmii-en" property for the DaVinci
> EMAC binding seems actually optional, as the driver should happily work without
> it; the property is not specified either in the example device node or in the
> actual EMAC device node for DA850 device tree, only AM3517 one.
>
> While at it, document the property better...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> Actually I think this property should have been boolean...
>
> Documentation/devicetree/bindings/net/davinci_emac.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: net/Documentation/devicetree/bindings/net/davinci_emac.txt
> ===================================================================
> --- net.orig/Documentation/devicetree/bindings/net/davinci_emac.txt
> +++ net/Documentation/devicetree/bindings/net/davinci_emac.txt
> @@ -10,7 +10,6 @@ Required properties:
> - ti,davinci-ctrl-mod-reg-offset: offset to control module register
> - ti,davinci-ctrl-ram-offset: offset to control module ram
> - ti,davinci-ctrl-ram-size: size of control module ram
> -- ti,davinci-rmii-en: use RMII
> - ti,davinci-no-bd-ram: has the emac controller BD RAM
> - interrupts: interrupt mapping for the davinci emac interrupts sources:
> 4 sources: <Receive Threshold Interrupt
> @@ -22,6 +21,7 @@ Optional properties:
> - phy-handle: Contains a phandle to an Ethernet PHY.
> If absent, davinci_emac driver defaults to 100/FULL.
> - local-mac-address : 6 bytes, mac address
> +- ti,davinci-rmii-en: 1 byte, 1 means use RMII
This just made me look at the actual DT binding documentation and the
driver, but there is support for specifying a PHY device tree node,
but no corresponding 'phy-connection-type' property which would tell
whether the connection is Reduced MII, MII or something else.
'phy-connection-type' would convey much more information about what is
happening, and once know, should also make the driver automatically
configure for Reduced MII or anything else, hence making
"ti,davinc-rmii-en" obsolete.
--
Florian
^ permalink raw reply
* Re: [RFC PATCH V2 1/4] pci: APM X-Gene PCIe controller driver
From: Tanmay Inamdar @ 2014-01-27 22:54 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel@lists.infradead.org, devicetree, Jon Masters,
linux-doc, Catalin Marinas, patches, linux-kernel@vger.kernel.org,
Jason Gunthorpe, Grant Likely, Rob Herring, Rob Landley,
linux-pci, Bjorn Helgaas
In-Reply-To: <5086198.ZOWZ5xuyna@wuerfel>
On Sat, Jan 25, 2014 at 12:11 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 24 January 2014 13:28:22 Tanmay Inamdar wrote:
>> On Thu, Jan 16, 2014 at 5:10 PM, Tanmay Inamdar <tinamdar@apm.com> wrote:
>> > On Wed, Jan 15, 2014 at 4:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> >> On Wednesday 15 January 2014, Tanmay Inamdar wrote:
>
>> >>
>> >>> +static void xgene_pcie_poll_linkup(struct xgene_pcie_port *port, u32 *lanes)
>> >>> +{
>> >>> + void *csr_base = port->csr_base;
>> >>> + u32 val32;
>> >>> + u64 start_time, time;
>> >>> +
>> >>> + /*
>> >>> + * A component enters the LTSSM Detect state within
>> >>> + * 20ms of the end of fundamental core reset.
>> >>> + */
>> >>> + msleep(XGENE_LTSSM_DETECT_WAIT);
>> >>> + port->link_up = 0;
>> >>> + start_time = jiffies;
>> >>> + do {
>> >>> + val32 = readl(csr_base + PCIECORE_CTLANDSTATUS);
>> >>> + if (val32 & LINK_UP_MASK) {
>> >>> + port->link_up = 1;
>> >>> + port->link_speed = PIPE_PHY_RATE_RD(val32);
>> >>> + val32 = readl(csr_base + BRIDGE_STATUS_0);
>> >>> + *lanes = val32 >> 26;
>> >>> + }
>> >>> + time = jiffies_to_msecs(jiffies - start_time);
>> >>> + } while ((!port->link_up) || (time <= XGENE_LTSSM_L0_WAIT));
>> >>> +}
>> >>
>> >> Maybe another msleep() in the loop? It seems weird to first do an
>> >> unconditional sleep but then busy-wait for the result.
>> >
>> > ok.
>>
>> This loop can execute for maximum 4 msec. So putting msleep(1) won't
>> get us much.
>
> 4 msec is still quite a long time for a busy loop that can be spent doing
> useful work in another thread.
>
Right. If 'msleep(1)' is used, then 'checkpatch' throws a warning
saying that it can actually sleep for 20ms in some cases. I will check
if 'usleep_range' is useful here.
>> >>
>> >> Another general note: Your "compatible" strings are rather unspecific.
>> >> Do you have a version number for this IP block? I suppose that it's related
>> >> to one that has been used in other chips before, or will be used in future
>> >> chips, if it's not actually licensed from some other company.
>> >
>> > I will have to check this.
>> >
>>
>> We have decided to stick with current compatible string for now.
>
> Can you elaborate on your reasoning? Does this mean X-Gene is a one-off
> product and you won't be doing any new chips based on the same hardware
> components?
The current convention is to key upon the family name - X-Gene. Future
chips will also be a part of X-Gene family. Right now it is unclear if
there are any obvious feature additions to be done in Linux PCIe
driver. Until then same driver is expected to work as is in future
chips.
>
> Arnd
^ permalink raw reply
* [PATCH v2] DT: net: document Ethernet bindings in one place
From: Sergei Shtylyov @ 2014-01-27 22:50 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
devicetree
Cc: rob, linux-doc, jcmvbkbc
This patch is an attempt to gather the Ethernet related bindings in one file,
like it's done in the MMC and some other subsystems. It should save some of
the trouble of documenting several properties over and over in each binding
document, instead only making reference to the main file.
I have used the Embedded Power Architecture(TM) Platform Requirements (ePAPR)
standard as a base for the properties description, also documenting some ad-hoc
properties that have been introduced over time despite having direct analogs in
ePAPR; hence I also attempt to make emphasis on using the standard properties
and marking ad-hoc properties as not recommended for new bindings.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
The patch is against DaveM's 'net-next.git' repo.
However, I'm not posting to netdev@vger.kernel.org this time or Dave will scold
me. :-)
Changes in version 2:
- restored the mentions of the common properties in the individual bindings, but
made them reference the common file instead;
- edited some property descriptions in the common file, indicating preferred and not recommended properties;
- moved the "max-frame-size" property definition to the common file, noting
about its contradictory definition in ePAPR 1.1;
- resolved rejects, refreshed the patch.
Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt | 5 --
Documentation/devicetree/bindings/net/arc_emac.txt | 10 +---
Documentation/devicetree/bindings/net/cavium-mix.txt | 7 +--
Documentation/devicetree/bindings/net/cavium-pip.txt | 7 +--
Documentation/devicetree/bindings/net/cdns-emac.txt | 5 --
Documentation/devicetree/bindings/net/cpsw.txt | 5 --
Documentation/devicetree/bindings/net/davicom-dm9000.txt | 3 -
Documentation/devicetree/bindings/net/davinci_emac.txt | 4 -
Documentation/devicetree/bindings/net/ethernet.txt | 22 ++++++++++
Documentation/devicetree/bindings/net/fsl-fec.txt | 6 --
Documentation/devicetree/bindings/net/fsl-tsec-phy.txt | 14 ++----
Documentation/devicetree/bindings/net/lpc-eth.txt | 6 +-
Documentation/devicetree/bindings/net/macb.txt | 5 --
Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt | 6 --
Documentation/devicetree/bindings/net/marvell-orion-net.txt | 4 -
Documentation/devicetree/bindings/net/micrel-ks8851.txt | 2
Documentation/devicetree/bindings/net/smsc-lan91c111.txt | 2
Documentation/devicetree/bindings/net/smsc911x.txt | 6 --
Documentation/devicetree/bindings/net/stmmac.txt | 8 +--
19 files changed, 63 insertions(+), 64 deletions(-)
Index: net-next/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
===================================================================
--- net-next.orig/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
+++ net-next/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
@@ -4,12 +4,11 @@ Required properties:
- compatible: should be "allwinner,sun4i-emac".
- reg: address and length of the register set for the device.
- interrupts: interrupt for the device
-- phy: A phandle to a phy node defining the PHY address (as the reg
- property, a single integer).
+- phy: see ethernet.txt file in the same directory.
- clocks: A phandle to the reference clock for this device
Optional properties:
-- (local-)mac-address: mac address to be used by this driver
+- [local-]mac-address: see ethernet.txt file in the same directory
Example:
Index: net-next/Documentation/devicetree/bindings/net/arc_emac.txt
===================================================================
--- net-next.orig/Documentation/devicetree/bindings/net/arc_emac.txt
+++ net-next/Documentation/devicetree/bindings/net/arc_emac.txt
@@ -6,18 +6,14 @@ Required properties:
- interrupts: Should contain the EMAC interrupts
- clock-frequency: CPU frequency. It is needed to calculate and set polling
period of EMAC.
-- max-speed: Maximum supported data-rate in Mbit/s. In some HW configurations
-bandwidth of external memory controller might be a limiting factor. That's why
-it's required to specify which data-rate is supported on current SoC or FPGA.
-For example if only 10 Mbit/s is supported (10BASE-T) set "10". If 100 Mbit/s is
-supported (100BASE-TX) set "100".
-- phy: PHY device attached to the EMAC via MDIO bus
+- max-speed: see ethernet.txt file in the same directory.
+- phy: see ethernet.txt file in the same directory.
Child nodes of the driver are the individual PHY devices connected to the
MDIO bus. They must have a "reg" property given the PHY address on the MDIO bus.
Optional properties:
-- mac-address: 6 bytes, mac address
+- mac-address: see ethernet.txt file in the same directory.
Examples:
Index: net-next/Documentation/devicetree/bindings/net/cavium-mix.txt
===================================================================
--- net-next.orig/Documentation/devicetree/bindings/net/cavium-mix.txt
+++ net-next/Documentation/devicetree/bindings/net/cavium-mix.txt
@@ -18,12 +18,11 @@ Properties:
- interrupts: Two interrupt specifiers. The first is the MIX
interrupt routing and the second the routing for the AGL interrupts.
-- mac-address: Optional, the MAC address to assign to the device.
+- mac-address: Optional, see ethernet.txt file in the same directory.
-- local-mac-address: Optional, the MAC address to assign to the device
- if mac-address is not specified.
+- local-mac-address: Optional, see ethernet.txt file in the same directory.
-- phy-handle: Optional, a phandle for the PHY device connected to this device.
+- phy-handle: Optional, see ethernet.txt file in the same directory.
Example:
ethernet@1070000100800 {
Index: net-next/Documentation/devicetree/bindings/net/cavium-pip.txt
===================================================================
--- net-next.orig/Documentation/devicetree/bindings/net/cavium-pip.txt
+++ net-next/Documentation/devicetree/bindings/net/cavium-pip.txt
@@ -35,12 +35,11 @@ Properties for PIP port which is a child
- reg: The port number within the interface group.
-- mac-address: Optional, the MAC address to assign to the device.
+- mac-address: Optional, see ethernet.txt file in the same directory.
-- local-mac-address: Optional, the MAC address to assign to the device
- if mac-address is not specified.
+- local-mac-address: Optional, see ethernet.txt file in the same directory.
-- phy-handle: Optional, a phandle for the PHY device connected to this device.
+- phy-handle: Optional, see ethernet.txt file in the same directory.
Example:
Index: net-next/Documentation/devicetree/bindings/net/cdns-emac.txt
===================================================================
--- net-next.orig/Documentation/devicetree/bindings/net/cdns-emac.txt
+++ net-next/Documentation/devicetree/bindings/net/cdns-emac.txt
@@ -6,11 +6,10 @@ Required properties:
or the generic form: "cdns,emac".
- reg: Address and length of the register set for the device
- interrupts: Should contain macb interrupt
-- phy-mode: String, operation mode of the PHY interface.
- Supported values are: "mii", "rmii".
+- phy-mode: see ethernet.txt file in the same directory.
Optional properties:
-- local-mac-address: 6 bytes, mac address
+- local-mac-address: see ethernet.txt file in the same directory
Examples:
Index: net-next/Documentation/devicetree/bindings/net/cpsw.txt
===================================================================
--- net-next.orig/Documentation/devicetree/bindings/net/cpsw.txt
+++ net-next/Documentation/devicetree/bindings/net/cpsw.txt
@@ -28,9 +28,8 @@ Optional properties:
Slave Properties:
Required properties:
- phy_id : Specifies slave phy id
-- phy-mode : The interface between the SoC and the PHY (a string
- that of_get_phy_mode() can understand)
-- mac-address : Specifies slave MAC address
+- phy-mode : See ethernet.txt file in the same directory
+- mac-address : See ethernet.txt file in the same directory
Optional properties:
- dual_emac_res_vlan : Specifies VID to be used to segregate the ports
Index: net-next/Documentation/devicetree/bindings/net/davicom-dm9000.txt
===================================================================
--- net-next.orig/Documentation/devicetree/bindings/net/davicom-dm9000.txt
+++ net-next/Documentation/devicetree/bindings/net/davicom-dm9000.txt
@@ -9,8 +9,7 @@ Required properties:
- interrupts : interrupt specifier specific to interrupt controller
Optional properties:
-- local-mac-address : A bytestring of 6 bytes specifying Ethernet MAC address
- to use (from firmware or bootloader)
+- local-mac-address : See ethernet.txt file in the same directory
- davicom,no-eeprom : Configuration EEPROM is not available
- davicom,ext-phy : Use external PHY
Index: net-next/Documentation/devicetree/bindings/net/davinci_emac.txt
===================================================================
--- net-next.orig/Documentation/devicetree/bindings/net/davinci_emac.txt
+++ net-next/Documentation/devicetree/bindings/net/davinci_emac.txt
@@ -19,9 +19,9 @@ Required properties:
Miscellaneous Interrupt>
Optional properties:
-- phy-handle: Contains a phandle to an Ethernet PHY.
+- phy-handle: See ethernet.txt file in the same directory.
If absent, davinci_emac driver defaults to 100/FULL.
-- local-mac-address : 6 bytes, mac address
+- local-mac-address: See ethernet.txt file in the same directory
Example (enbw_cmc board):
eth0: emac@1e20000 {
Index: net-next/Documentation/devicetree/bindings/net/ethernet.txt
===================================================================
--- /dev/null
+++ net-next/Documentation/devicetree/bindings/net/ethernet.txt
@@ -0,0 +1,22 @@
+The following properties are common to the Ethernet controllers:
+
+- local-mac-address: array of 6 bytes, specifies the MAC address that was
+ assigned to the network device;
+- mac-address: array of 6 bytes, specifies the MAC address that was last used by
+ the boot program; should be used in cases where the MAC address assigned to
+ the device by the boot program is different from the "local-mac-address"
+ property;
+- max-speed: number, specifies maximum speed in Mbit/s supported by the device;
+- max-frame-size: number, Maximum Transfer Unit (IEEE defined MTU), rather than the maximum frame size.
+- phy-mode: string, operation mode of the PHY interface; supported values are
+ "mii", "gmii", "sgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id",
+ "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii"; not recommended for new
+ bindings;
+- phy-connection-type: the same as "phy-mode" property but described in ePAPR;
+- phy-handle: phandle, specifies a reference to a node representing a PHY
+ device; this property is described in ePAPR and so preferred;
+- phy: the same as "phy-handle" property, not recommended for new bindings.
+
+Child nodes of the Ethernet controller are typically the individual PHY devices
+connected via the MDIO bus (sometimes the MDIO bus controller is separate).
+They are described in the phy.txt file in this same directory.
Index: net-next/Documentation/devicetree/bindings/net/fsl-fec.txt
===================================================================
--- net-next.orig/Documentation/devicetree/bindings/net/fsl-fec.txt
+++ net-next/Documentation/devicetree/bindings/net/fsl-fec.txt
@@ -4,12 +4,10 @@ Required properties:
- compatible : Should be "fsl,<soc>-fec"
- reg : Address and length of the register set for the device
- interrupts : Should contain fec interrupt
-- phy-mode : String, operation mode of the PHY interface.
- Supported values are: "mii", "gmii", "sgmii", "tbi", "rmii",
- "rgmii", "rgmii-id", "rgmii-rxid", "rgmii-txid", "rtbi", "smii".
+- phy-mode : See ethernet.txt file in the same directory
Optional properties:
-- local-mac-address : 6 bytes, mac address
+- local-mac-address : See ethernet.txt file in the same directory
- phy-reset-gpios : Should specify the gpio for phy reset
- phy-reset-duration : Reset duration in milliseconds. Should present
only if property "phy-reset-gpios" is available. Missing the property
Index: net-next/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
===================================================================
--- net-next.orig/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
+++ net-next/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
@@ -38,22 +38,18 @@ Properties:
- model : Model of the device. Can be "TSEC", "eTSEC", or "FEC"
- compatible : Should be "gianfar"
- reg : Offset and length of the register set for the device
- - local-mac-address : List of bytes representing the ethernet address of
- this controller
+ - local-mac-address : See ethernet.txt file in the same directory
- interrupts : For FEC devices, the first interrupt is the device's
interrupt. For TSEC and eTSEC devices, the first interrupt is
transmit, the second is receive, and the third is error.
- - phy-handle : The phandle for the PHY connected to this ethernet
- controller.
+ - phy-handle : See ethernet.txt file in the same directory.
- fixed-link : <a b c d e> where a is emulated phy id - choose any,
but unique to the all specified fixed-links, b is duplex - 0 half,
1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no
pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause.
- - phy-connection-type : a string naming the controller/PHY interface type,
- i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "sgmii",
- "tbi", or "rtbi". This property is only really needed if the connection
- is of type "rgmii-id", as all other connection types are detected by
- hardware.
+ - phy-connection-type : See ethernet.txt file in the same directory.
+ This property is only really needed if the connection is of type
+ "rgmii-id", as all other connection types are detected by hardware.
- fsl,magic-packet : If present, indicates that the hardware supports
waking up via magic packet.
- bd-stash : If present, indicates that the hardware supports stashing
Index: net-next/Documentation/devicetree/bindings/net/lpc-eth.txt
===================================================================
--- net-next.orig/Documentation/devicetree/bindings/net/lpc-eth.txt
+++ net-next/Documentation/devicetree/bindings/net/lpc-eth.txt
@@ -6,10 +6,10 @@ Required properties:
- interrupts: Should contain ethernet controller interrupt
Optional properties:
-- phy-mode: String, operation mode of the PHY interface.
- Supported values are: "mii", "rmii" (default)
+- phy-mode: See ethernet.txt file in the same directory. If the property is
+ absent, "rmii" is assumed.
- use-iram: Use LPC32xx internal SRAM (IRAM) for DMA buffering
-- local-mac-address : 6 bytes, mac address
+- local-mac-address : See ethernet.txt file in the same directory
Example:
Index: net-next/Documentation/devicetree/bindings/net/macb.txt
===================================================================
--- net-next.orig/Documentation/devicetree/bindings/net/macb.txt
+++ net-next/Documentation/devicetree/bindings/net/macb.txt
@@ -8,15 +8,14 @@ Required properties:
the Cadence GEM, or the generic form: "cdns,gem".
- reg: Address and length of the register set for the device
- interrupts: Should contain macb interrupt
-- phy-mode: String, operation mode of the PHY interface.
- Supported values are: "mii", "rmii", "gmii", "rgmii".
+- phy-mode: See ethernet.txt file in the same directory.
- clock-names: Tuple listing input clock names.
Required elements: 'pclk', 'hclk'
Optional elements: 'tx_clk'
- clocks: Phandles to input clocks.
Optional properties:
-- local-mac-address: 6 bytes, mac address
+- local-mac-address: See ethernet.txt file in the same directory
Examples:
Index: net-next/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
===================================================================
--- net-next.orig/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
+++ net-next/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
@@ -4,10 +4,8 @@ Required properties:
- compatible: should be "marvell,armada-370-neta".
- reg: address and length of the register set for the device.
- interrupts: interrupt for the device
-- phy: A phandle to a phy node defining the PHY address (as the reg
- property, a single integer).
-- phy-mode: The interface between the SoC and the PHY (a string that
- of_get_phy_mode() can understand)
+- phy: See ethernet.txt file in the same directory.
+- phy-mode: See ethernet.txt file in the same directory
- clocks: a pointer to the reference clock for this device.
Example:
Index: net-next/Documentation/devicetree/bindings/net/marvell-orion-net.txt
===================================================================
--- net-next.orig/Documentation/devicetree/bindings/net/marvell-orion-net.txt
+++ net-next/Documentation/devicetree/bindings/net/marvell-orion-net.txt
@@ -36,7 +36,7 @@ Required port properties:
"marvell,kirkwood-eth-port".
- reg: port number relative to ethernet controller, shall be 0, 1, or 2.
- interrupts: port interrupt.
- - local-mac-address: 6 bytes MAC address.
+ - local-mac-address: See ethernet.txt file in the same directory.
Optional port properties:
- marvell,tx-queue-size: size of the transmit ring buffer.
@@ -48,7 +48,7 @@ Optional port properties:
and
- - phy-handle: phandle reference to ethernet PHY.
+ - phy-handle: See ethernet.txt file in the same directory.
or
Index: net-next/Documentation/devicetree/bindings/net/micrel-ks8851.txt
===================================================================
--- net-next.orig/Documentation/devicetree/bindings/net/micrel-ks8851.txt
+++ net-next/Documentation/devicetree/bindings/net/micrel-ks8851.txt
@@ -6,4 +6,4 @@ Required properties:
- interrupts : interrupt connection
Optional properties:
-- local-mac-address : Ethernet mac address to use
+- local-mac-address : See ethernet.txt file in the same directory
Index: net-next/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
===================================================================
--- net-next.orig/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
+++ net-next/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
@@ -7,7 +7,7 @@ Required properties:
Optional properties:
- phy-device : phandle to Ethernet phy
-- local-mac-address : Ethernet mac address to use
+- local-mac-address : See ethernet.txt file in the same directory
- reg-io-width : Mask of sizes (in bytes) of the IO accesses that
are supported on the device. Valid value for SMSC LAN91c111 are
1, 2 or 4. If it's omitted or invalid, the size would be 2 meaning
Index: net-next/Documentation/devicetree/bindings/net/smsc911x.txt
===================================================================
--- net-next.orig/Documentation/devicetree/bindings/net/smsc911x.txt
+++ net-next/Documentation/devicetree/bindings/net/smsc911x.txt
@@ -6,9 +6,7 @@ Required properties:
- interrupts : Should contain SMSC LAN interrupt line
- interrupt-parent : Should be the phandle for the interrupt controller
that services interrupts for this device
-- phy-mode : String, operation mode of the PHY interface.
- Supported values are: "mii", "gmii", "sgmii", "tbi", "rmii",
- "rgmii", "rgmii-id", "rgmii-rxid", "rgmii-txid", "rtbi", "smii".
+- phy-mode : See ethernet.txt file in the same directory
Optional properties:
- reg-shift : Specify the quantity to shift the register offsets by
@@ -23,7 +21,7 @@ Optional properties:
external PHY
- smsc,save-mac-address : Indicates that mac address needs to be saved
before resetting the controller
-- local-mac-address : 6 bytes, mac address
+- local-mac-address : See ethernet.txt file in the same directory
Examples:
Index: net-next/Documentation/devicetree/bindings/net/stmmac.txt
===================================================================
--- net-next.orig/Documentation/devicetree/bindings/net/stmmac.txt
+++ net-next/Documentation/devicetree/bindings/net/stmmac.txt
@@ -10,8 +10,7 @@ Required properties:
- interrupt-names: Should contain the interrupt names "macirq"
"eth_wake_irq" if this interrupt is supported in the "interrupts"
property
-- phy-mode: String, operation mode of the PHY interface.
- Supported values are: "mii", "rmii", "gmii", "rgmii".
+- phy-mode: See ethernet.txt file in the same directory.
- snps,reset-gpio gpio number for phy reset.
- snps,reset-active-low boolean flag to indicate if phy reset is active low.
- snps,reset-delays-us is triplet of delays
@@ -28,12 +27,11 @@ Required properties:
ignored if force_thresh_dma_mode is set.
Optional properties:
-- mac-address: 6 bytes, mac address
+- mac-address: See ethernet.txt file in the same directory
- resets: Should contain a phandle to the STMMAC reset signal, if any
- reset-names: Should contain the reset signal name "stmmaceth", if a
reset phandle is given
-- max-frame-size: Maximum Transfer Unit (IEEE defined MTU), rather
- than the maximum frame size.
+- max-frame-size: See ethernet.txt file in the same directory
Examples:
^ permalink raw reply
* Re: [PATCH 1/3] net: ethoc: don't advertise gigabit speed on attached PHY
From: Florian Fainelli @ 2014-01-27 22:31 UTC (permalink / raw)
To: Max Filippov
Cc: Ben Hutchings, linux-xtensa@linux-xtensa.org, netdev,
devicetree@vger.kernel.org, LKML, Chris Zankel, Marc Gauthier,
David S. Miller, Grant Likely, Rob Herring
In-Reply-To: <CAMo8BfLx9iVTqW9fQonF=7C=oDG1RpU5iyGUXf_wFnk7TEvShA@mail.gmail.com>
(fixing Rob's email)
2014-01-27 Max Filippov <jcmvbkbc@gmail.com>:
> On Mon, Jan 27, 2014 at 11:36 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> 2014-01-27 Max Filippov <jcmvbkbc@gmail.com>:
>>> On Mon, Jan 27, 2014 at 2:18 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
>>>> On Mon, 2014-01-27 at 07:59 +0400, Max Filippov wrote:
>>>>> OpenCores 10/100 Mbps MAC does not support speeds above 100 Mbps, but does
>>>>> not disable advertisement when PHY supports them. This results in
>>>>> non-functioning network when the MAC is connected to a gigabit PHY connected
>>>>> to a gigabit switch.
>>>>>
>>>>> The fix is to disable gigabit speed advertisement on attached PHY
>>>>> unconditionally.
>>>>>
>>>>> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
>>>>> ---
>>>>> drivers/net/ethernet/ethoc.c | 2 ++
>>>>> 1 file changed, 2 insertions(+)
>>>>>
>>>>> diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
>>>>> index 4de8cfd..0aa1a05 100644
>>>>> --- a/drivers/net/ethernet/ethoc.c
>>>>> +++ b/drivers/net/ethernet/ethoc.c
>>>>> @@ -712,6 +712,8 @@ static int ethoc_open(struct net_device *dev)
>>>>> netif_start_queue(dev);
>>>>> }
>>>>>
>>>>> + priv->phy->advertising &= ~(ADVERTISED_1000baseT_Full |
>>>>> + ADVERTISED_1000baseT_Half);
>>>>> phy_start(priv->phy);
>>>>> napi_enable(&priv->napi);
>>>>>
>>>>
>>>> This is not sufficient to disable gigabit speeds; the supported mask
>>>> should also be limited. And it should be done even before the net
>>>
>>> I tried that, but when I also limit supported mask the phy driver doesn't
>>> touch gigabit advertising register int the genphy_config_advert at all.
>>> That's probably right for ethtool interface, but ethoc doesn't support
>>> ethtool.
>>
>> This is not right for libphy either, phydev->supported must reflect
>> that you support Gigabit or not.
>
> I'm sorry, does that mean that I must not touch phydev->supported,
> or that I must update it too and somehow fix genphy_config_advert?
What I meant is that your driver has to set both phydev->advertising
and phydev->supported. genphy_config_advert() is doing
phdev->advertising &= phydev->supported, leaving phydev->supported to
something more restrictive will produce unexpected results. This is
also important if phy_driver::config_aneg() is not using the generic
implementation and directly uses/modifies phydev->advertising and
phydev->supported.
It seems like there is room for improvements in that area regardless
of how we access things. For instance, specifying the PHY interface
mode (MII, GMII etc...) should already provide a hint of what
phydev->supported should look like. You cannot do Gigabit with MII for
instance.
>
>> Since ethoc supports libphy, there really is no reason not to
>> implement the ethtool_{get,set}_settings callbacks using
>> phy_mii_ioctl().
>
> Ok, I'll add that.
>
>>>> device is registered.
>>>>
>>>> Rather than poking into the phy_device structure directly from this
>>>> driver, I think you should add a function in phylib for this purpose.
>>
>> All drivers are currently modifying phydev->advertising and
>> phydev->supported directly, most of them do it correctly as far as I
>> checked. It does make some sense to add a helper function though.
>
> [...]
>
>>> diff --git a/include/linux/phy.h b/include/linux/phy.h
>>> index 48a4dc3..0282a8d 100644
>>> --- a/include/linux/phy.h
>>> +++ b/include/linux/phy.h
>>> @@ -559,6 +559,11 @@ static inline int phy_read_status(struct phy_device *phydev) {
>>> return phydev->drv->read_status(phydev);
>>> }
>>>
>>> +static inline void phy_update_adv(struct phy_device *phydev, u32 mask, u32 set)
>>> +{
>>> + phydev->advertising = (phydev->advertising & mask) | set;
>>> +}
>>> +
>>
>> This should be a preliminary patch to this patchset, so you first
>> introduce the function, then use it in the driver, but the idea looks
>> good. There is room for updating quite some drivers out there since
>> those used to modify phydev->advertising and phydev->supported
>> directly without using an accessor.
>
> What about those that do something like this:
>
> phydev->advertising = phydev->supported;
>
> leave them as is, or provide read accessor for phydev->supported?
Those should be just fine since genphy_config_advert() does
phydev->advertising &= phydev->supported, so the end result will be
identical. You mean a write accessor instead of a read accessor?
--
Florian
^ permalink raw reply
* Re: [PATCH RESEND v2 00/12] clk/exynos convert clock IDs to macros
From: Mike Turquette @ 2014-01-27 21:49 UTC (permalink / raw)
To: Tomasz Figa
Cc: moderated list:OPEN FIRMWARE AND..., Kukjin Kim, Andrzej Hajda,
Kyungmin Park, moderated list:ARM/S5P EXYNOS AR...,
linux-arm-kernel
In-Reply-To: <1514827.Cd6xxeNpq2@amdc1227>
Quoting Tomasz Figa (2014-01-07 07:17:22)
> Hi Mike,
>
> On Tuesday 07 of January 2014 15:47:28 Andrzej Hajda wrote:
> > Hi,
> >
> > This patch set adds header files with macros defining exynos clocks.
> > Then it converts dts files and drivers to use macros instead
> > of magic numbers or enums to describe clock bindings.
> >
> > The patch set is rebased on the latest samsung-clk/samsung-next branch.
> >
> > The patches are generated by script.
> > Many clocks I have verified by hand.
> > I have also tested it successfully on exynos4 based board.
> >
> > This is the 2nd version of the patchset.
> > Changes:
> > - corrected devicetree mailing list,
> > - added comments to include/dt-bindings/clock/exynos4.h for
> > clocks present only in particular chip,
> > - added tab alignement in headers,
> > - added comment to CLK_NR_CLKS,
> > - added copyright headers,
> > - split long lines in dts,
> > - corrected example in bindings/clock/exynos5250-clock.txt, to point
> > appropriate clocks.
>
> I believe this has been already acked before, so could you still take
> it for 3.14? For now I'd merge only the patches adding headers and
> updating clock drivers to avoid merge conflicts and then after
> release of 3.14-rc1 we could early merge dts patches for 3.15.
Hi Tomasz,
Let's go ahead and merge this after 3.14-rc1. I'll take it in when that
drops and the DTS data will go in during the same merge window.
Regards,
Mike
>
> What do you think?
>
> Best regards,
> Tomasz
>
^ permalink raw reply
* Re: [PATCH 3/3] net: ethoc: document OF bindings
From: Florian Fainelli @ 2014-01-27 21:12 UTC (permalink / raw)
To: Max Filippov
Cc: Rob Herring, linux-xtensa@linux-xtensa.org, netdev,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Chris Zankel, Marc Gauthier, David S. Miller, Grant Likely,
Rob Herring
In-Reply-To: <CAMo8BfLhFyOY1+FJ0qh8iL969totUCmHdJ0LzyqBAzwi1-Ht=A@mail.gmail.com>
2014-01-27 Max Filippov <jcmvbkbc@gmail.com>:
> On Mon, Jan 27, 2014 at 11:45 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> 2014-01-27 Max Filippov <jcmvbkbc@gmail.com>:
>>> On Mon, Jan 27, 2014 at 6:10 PM, Rob Herring <robherring2@gmail.com> wrote:
>>>> On Sun, Jan 26, 2014 at 9:59 PM, Max Filippov <jcmvbkbc@gmail.com> wrote:
>
> [...]
>
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/net/opencores-ethoc.txt
>>>>> @@ -0,0 +1,25 @@
>>>>> +* OpenCores MAC 10/100 Mbps
>>>>> +
>>>>> +Required properties:
>>>>> +- compatible: Should be "opencores,ethoc".
>>>>
>>>> There are not different versions of IP or is the version probeable?
>>>
>>> AFAIK there's single version of this 10/100 MAC.
>>> It doesn't have any identification registers.
>>
>> Since this is an IP block that people can modify due to its open
>> source nature, it would have been good to define a revision register
>> or such which would allow software to gate specific code based on that
>> revision.
>
> Probably yes, though I haven't heard of any modified versions of this MAC
> out there.
>
> [...]
>
>>>>> +Examples:
>>>>> +
>>>>> + enet0: ethoc@fd030000 {
>>>>> + compatible = "opencores,ethoc";
>>>>> + reg = <0xfd030000 0x4000 0xfd800000 0x4000>;
>>>>> + interrupts = <1>;
>>>>> + local-mac-address = [00 50 c2 13 6f 00];
>>>>> + clock-frequency = <50000000>;
>>>>> + mii-mgmt-clock-frequency = <5000000>;
>>
>> 5Mhz management clock? Can't you make it work with the standard 2.5Mhz
>> management clock? Is not there a risk not to be able to "talk" to some
>> PHY chips out there which do not support > 2.5Mhz management clock?
>
> Yes I can, it just didn't occur to me that there is a standard 2.5MHz setting.
>
>> Since this is an ethoc specific property, should it be prefixed with "ethoc,"?
>
> Is it worth keeping this parameter at all, or just always default to 2.5MHz?
Your example lists 5Mhz, so I assume this is of some use for you on
the platform you are working with? My concern is that this might not
be compatible with all PHY devices out there and might create hard to
debug issues where you get some MDIO transactions to succeeds and some
which don't.
--
Florian
^ permalink raw reply
* Re: [PATCH 3/4] ASoC: tda998x: add DT documentation
From: Mark Brown @ 2014-01-27 20:56 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Jean-Francois Moine, alsa-devel, devicetree, Dave Airlie,
dri-devel, linux-arm-kernel, linux-kernel, Rob Clark
In-Reply-To: <20140127204534.GB15937@n2100.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 764 bytes --]
On Mon, Jan 27, 2014 at 08:45:34PM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 27, 2014 at 08:43:02PM +0000, Mark Brown wrote:
> > On Mon, Jan 27, 2014 at 09:34:49AM +0100, Jean-Francois Moine wrote:
> > > + - audio-ports: one or two values.
> > > + The first value defines the I2S input port.
> > > + The second one, if present, defines the S/PDIF input port.
> > I take it these are port numbers on the device and it's not possible to
> > do something like having multiple I2S ports?
> You can feed it with multiple synchronised I2S streams for the additional
> channels.
Ah, I feared as much. The bindings ought to take account of that
posibility even if the code can't use additional ports yet. Perhaps
separate properties for I2S and S/PDIF?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] ASoC: tda998x: add DT documentation
From: Russell King - ARM Linux @ 2014-01-27 20:45 UTC (permalink / raw)
To: Mark Brown
Cc: Jean-Francois Moine, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA, Dave Airlie,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Clark
In-Reply-To: <20140127204302.GY11841-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
On Mon, Jan 27, 2014 at 08:43:02PM +0000, Mark Brown wrote:
> On Mon, Jan 27, 2014 at 09:34:49AM +0100, Jean-Francois Moine wrote:
>
> > + - compatible: must be "nxp,tda998x-codec".
> > + - audio-ports: one or two values.
> > + The first value defines the I2S input port.
> > + The second one, if present, defines the S/PDIF input port.
>
> I take it these are port numbers on the device and it's not possible to
> do something like having multiple I2S ports?
You can feed it with multiple synchronised I2S streams for the additional
channels.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] net: ethoc: document OF bindings
From: Max Filippov @ 2014-01-27 20:45 UTC (permalink / raw)
To: Florian Fainelli
Cc: Rob Herring, linux-xtensa-PjhNF2WwrV/0Sa2dR60CXw@public.gmane.org,
netdev, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Chris Zankel, Marc Gauthier, David S. Miller, Grant Likely,
Rob Herring
In-Reply-To: <CAGVrzcb4Y8zu6Q24-0d-uKppGE=HrvEXPUD2-Mo8r5JC80nDSw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Jan 27, 2014 at 11:45 PM, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 2014-01-27 Max Filippov <jcmvbkbc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>> On Mon, Jan 27, 2014 at 6:10 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> On Sun, Jan 26, 2014 at 9:59 PM, Max Filippov <jcmvbkbc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
[...]
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/net/opencores-ethoc.txt
>>>> @@ -0,0 +1,25 @@
>>>> +* OpenCores MAC 10/100 Mbps
>>>> +
>>>> +Required properties:
>>>> +- compatible: Should be "opencores,ethoc".
>>>
>>> There are not different versions of IP or is the version probeable?
>>
>> AFAIK there's single version of this 10/100 MAC.
>> It doesn't have any identification registers.
>
> Since this is an IP block that people can modify due to its open
> source nature, it would have been good to define a revision register
> or such which would allow software to gate specific code based on that
> revision.
Probably yes, though I haven't heard of any modified versions of this MAC
out there.
[...]
>>>> +Examples:
>>>> +
>>>> + enet0: ethoc@fd030000 {
>>>> + compatible = "opencores,ethoc";
>>>> + reg = <0xfd030000 0x4000 0xfd800000 0x4000>;
>>>> + interrupts = <1>;
>>>> + local-mac-address = [00 50 c2 13 6f 00];
>>>> + clock-frequency = <50000000>;
>>>> + mii-mgmt-clock-frequency = <5000000>;
>
> 5Mhz management clock? Can't you make it work with the standard 2.5Mhz
> management clock? Is not there a risk not to be able to "talk" to some
> PHY chips out there which do not support > 2.5Mhz management clock?
Yes I can, it just didn't occur to me that there is a standard 2.5MHz setting.
> Since this is an ethoc specific property, should it be prefixed with "ethoc,"?
Is it worth keeping this parameter at all, or just always default to 2.5MHz?
--
Thanks.
-- Max
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/4] ASoC: tda998x: add DT documentation
From: Mark Brown @ 2014-01-27 20:43 UTC (permalink / raw)
To: Jean-Francois Moine
Cc: alsa-devel, devicetree, Dave Airlie, dri-devel, linux-arm-kernel,
linux-kernel, Rob Clark, Russell King - ARM Linux
In-Reply-To: <22fafd7e11771ffc25c84ff609d18039f07b7295.1390813481.git.moinejf@free.fr>
[-- Attachment #1: Type: text/plain, Size: 386 bytes --]
On Mon, Jan 27, 2014 at 09:34:49AM +0100, Jean-Francois Moine wrote:
> + - compatible: must be "nxp,tda998x-codec".
> + - audio-ports: one or two values.
> + The first value defines the I2S input port.
> + The second one, if present, defines the S/PDIF input port.
I take it these are port numbers on the device and it's not possible to
do something like having multiple I2S ports?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] net: ethoc: don't advertise gigabit speed on attached PHY
From: Max Filippov @ 2014-01-27 20:36 UTC (permalink / raw)
To: Florian Fainelli
Cc: Ben Hutchings, linux-xtensa@linux-xtensa.org, netdev,
devicetree@vger.kernel.org, LKML, Chris Zankel, Marc Gauthier,
David S. Miller, Grant Likely, Rob Herring
In-Reply-To: <CAGVrzcZ15Ov4zFDkaX=YuK0xVa+_QVjha1TN0cnhoMHYh1Jx4Q@mail.gmail.com>
On Mon, Jan 27, 2014 at 11:36 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> 2014-01-27 Max Filippov <jcmvbkbc@gmail.com>:
>> On Mon, Jan 27, 2014 at 2:18 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
>>> On Mon, 2014-01-27 at 07:59 +0400, Max Filippov wrote:
>>>> OpenCores 10/100 Mbps MAC does not support speeds above 100 Mbps, but does
>>>> not disable advertisement when PHY supports them. This results in
>>>> non-functioning network when the MAC is connected to a gigabit PHY connected
>>>> to a gigabit switch.
>>>>
>>>> The fix is to disable gigabit speed advertisement on attached PHY
>>>> unconditionally.
>>>>
>>>> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
>>>> ---
>>>> drivers/net/ethernet/ethoc.c | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
>>>> index 4de8cfd..0aa1a05 100644
>>>> --- a/drivers/net/ethernet/ethoc.c
>>>> +++ b/drivers/net/ethernet/ethoc.c
>>>> @@ -712,6 +712,8 @@ static int ethoc_open(struct net_device *dev)
>>>> netif_start_queue(dev);
>>>> }
>>>>
>>>> + priv->phy->advertising &= ~(ADVERTISED_1000baseT_Full |
>>>> + ADVERTISED_1000baseT_Half);
>>>> phy_start(priv->phy);
>>>> napi_enable(&priv->napi);
>>>>
>>>
>>> This is not sufficient to disable gigabit speeds; the supported mask
>>> should also be limited. And it should be done even before the net
>>
>> I tried that, but when I also limit supported mask the phy driver doesn't
>> touch gigabit advertising register int the genphy_config_advert at all.
>> That's probably right for ethtool interface, but ethoc doesn't support
>> ethtool.
>
> This is not right for libphy either, phydev->supported must reflect
> that you support Gigabit or not.
I'm sorry, does that mean that I must not touch phydev->supported,
or that I must update it too and somehow fix genphy_config_advert?
> Since ethoc supports libphy, there really is no reason not to
> implement the ethtool_{get,set}_settings callbacks using
> phy_mii_ioctl().
Ok, I'll add that.
>>> device is registered.
>>>
>>> Rather than poking into the phy_device structure directly from this
>>> driver, I think you should add a function in phylib for this purpose.
>
> All drivers are currently modifying phydev->advertising and
> phydev->supported directly, most of them do it correctly as far as I
> checked. It does make some sense to add a helper function though.
[...]
>> diff --git a/include/linux/phy.h b/include/linux/phy.h
>> index 48a4dc3..0282a8d 100644
>> --- a/include/linux/phy.h
>> +++ b/include/linux/phy.h
>> @@ -559,6 +559,11 @@ static inline int phy_read_status(struct phy_device *phydev) {
>> return phydev->drv->read_status(phydev);
>> }
>>
>> +static inline void phy_update_adv(struct phy_device *phydev, u32 mask, u32 set)
>> +{
>> + phydev->advertising = (phydev->advertising & mask) | set;
>> +}
>> +
>
> This should be a preliminary patch to this patchset, so you first
> introduce the function, then use it in the driver, but the idea looks
> good. There is room for updating quite some drivers out there since
> those used to modify phydev->advertising and phydev->supported
> directly without using an accessor.
What about those that do something like this:
phydev->advertising = phydev->supported;
leave them as is, or provide read accessor for phydev->supported?
--
Thanks.
-- Max
^ permalink raw reply
* Re: [PATCH v3 2/2] regulator: s5m8767: Document new binding for Buck9 GPIO control
From: Mark Brown @ 2014-01-27 20:25 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Sangbeom Kim, Liam Girdwood, Samuel Ortiz, Lee Jones,
linux-kernel, devicetree, linux-samsung-soc, Sachin Kamat,
Kyungmin Park, Marek Szyprowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <1390570678-30686-3-git-send-email-k.kozlowski@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 197 bytes --]
On Fri, Jan 24, 2014 at 02:37:58PM +0100, Krzysztof Kozlowski wrote:
> Add documentation for new binding for controlling (enable/disable) the
> Buck9 Converter by GPIO (BUCK9EN).
Applied, thanks.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] regulator: s5m8767: Use GPIO for controlling Buck9/eMMC
From: Mark Brown @ 2014-01-27 20:25 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Sangbeom Kim, Liam Girdwood, Samuel Ortiz, Lee Jones,
linux-kernel, devicetree, linux-samsung-soc, Sachin Kamat,
Kyungmin Park, Marek Szyprowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <1390570678-30686-2-git-send-email-k.kozlowski@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 215 bytes --]
On Fri, Jan 24, 2014 at 02:37:57PM +0100, Krzysztof Kozlowski wrote:
> Add support for GPIO control (enable/disable) over Buck9. The Buck9
> Converter is used as a supply for eMMC Host Controller.
Applied, thanks.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4 13/14] spi: rspi: Add DT support
From: Mark Brown @ 2014-01-27 20:11 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-spi, linux-sh, linux-kernel, Geert Uytterhoeven, devicetree
In-Reply-To: <1390553044-11860-14-git-send-email-geert@linux-m68k.org>
[-- Attachment #1: Type: text/plain, Size: 300 bytes --]
On Fri, Jan 24, 2014 at 09:44:03AM +0100, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
> Cc: devicetree@vger.kernel.org
This looks good modulo Mark's comment on the binding document.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] net: ethoc: document OF bindings
From: Florian Fainelli @ 2014-01-27 19:45 UTC (permalink / raw)
To: Max Filippov
Cc: Rob Herring, linux-xtensa-PjhNF2WwrV/0Sa2dR60CXw@public.gmane.org,
netdev, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Chris Zankel, Marc Gauthier, David S. Miller, Grant Likely,
Rob Herring
In-Reply-To: <CAMo8BfKm_rzDDs9BpfQkaew9DP9T8y0RnjzT_1gzs9Xrbx2CLA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-01-27 Max Filippov <jcmvbkbc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> Hi Rob,
>
> On Mon, Jan 27, 2014 at 6:10 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Sun, Jan 26, 2014 at 9:59 PM, Max Filippov <jcmvbkbc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> Signed-off-by: Max Filippov <jcmvbkbc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> ---
>>> .../devicetree/bindings/net/opencores-ethoc.txt | 25 ++++++++++++++++++++++
>>> 1 file changed, 25 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/net/opencores-ethoc.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/opencores-ethoc.txt b/Documentation/devicetree/bindings/net/opencores-ethoc.txt
>>> new file mode 100644
>>> index 0000000..f7c6c94
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/net/opencores-ethoc.txt
>>> @@ -0,0 +1,25 @@
>>> +* OpenCores MAC 10/100 Mbps
>>> +
>>> +Required properties:
>>> +- compatible: Should be "opencores,ethoc".
>>
>> There are not different versions of IP or is the version probeable?
>
> AFAIK there's single version of this 10/100 MAC.
> It doesn't have any identification registers.
Since this is an IP block that people can modify due to its open
source nature, it would have been good to define a revision register
or such which would allow software to gate specific code based on that
revision.
>
>>> +- reg: Address and length of the register set for the device and of its
>>> + descriptor memory.
>>> +- interrupts: Should contain ethoc interrupt.
>>> +
>>> +Optional properties:
>>> +- local-mac-address: 6 bytes, mac address
>>
>> There's a patch in progress to move all the standard network
>> properties to a common location, so you can remove this.
>
> Will do.
>
>>> +- clock-frequency: basic MAC frequency.
>>> +- mii-mgmt-clock-frequency: frequency of MII management bus. Together
>>> + with clock-frequency determines the value programmed into the CLKDIV
>>> + field of MIIMODER register.
>>> +
>>> +Examples:
>>> +
>>> + enet0: ethoc@fd030000 {
>>> + compatible = "opencores,ethoc";
>>> + reg = <0xfd030000 0x4000 0xfd800000 0x4000>;
>>> + interrupts = <1>;
>>> + local-mac-address = [00 50 c2 13 6f 00];
>>> + clock-frequency = <50000000>;
>>> + mii-mgmt-clock-frequency = <5000000>;
5Mhz management clock? Can't you make it work with the standard 2.5Mhz
management clock? Is not there a risk not to be able to "talk" to some
PHY chips out there which do not support > 2.5Mhz management clock?
Since this is an ethoc specific property, should it be prefixed with "ethoc,"?
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] net: ethoc: don't advertise gigabit speed on attached PHY
From: Florian Fainelli @ 2014-01-27 19:36 UTC (permalink / raw)
To: Max Filippov
Cc: Ben Hutchings,
linux-xtensa-PjhNF2WwrV/0Sa2dR60CXw@public.gmane.org, netdev,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, LKML,
Chris Zankel, Marc Gauthier, David S. Miller, Grant Likely,
Rob Herring
In-Reply-To: <52E6868C.3070401-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-01-27 Max Filippov <jcmvbkbc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> Hi Ben,
>
> On Mon, Jan 27, 2014 at 2:18 PM, Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org> wrote:
>> On Mon, 2014-01-27 at 07:59 +0400, Max Filippov wrote:
>>> OpenCores 10/100 Mbps MAC does not support speeds above 100 Mbps, but does
>>> not disable advertisement when PHY supports them. This results in
>>> non-functioning network when the MAC is connected to a gigabit PHY connected
>>> to a gigabit switch.
>>>
>>> The fix is to disable gigabit speed advertisement on attached PHY
>>> unconditionally.
>>>
>>> Signed-off-by: Max Filippov <jcmvbkbc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> ---
>>> drivers/net/ethernet/ethoc.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
>>> index 4de8cfd..0aa1a05 100644
>>> --- a/drivers/net/ethernet/ethoc.c
>>> +++ b/drivers/net/ethernet/ethoc.c
>>> @@ -712,6 +712,8 @@ static int ethoc_open(struct net_device *dev)
>>> netif_start_queue(dev);
>>> }
>>>
>>> + priv->phy->advertising &= ~(ADVERTISED_1000baseT_Full |
>>> + ADVERTISED_1000baseT_Half);
>>> phy_start(priv->phy);
>>> napi_enable(&priv->napi);
>>>
>>
>> This is not sufficient to disable gigabit speeds; the supported mask
>> should also be limited. And it should be done even before the net
>
> I tried that, but when I also limit supported mask the phy driver doesn't
> touch gigabit advertising register int the genphy_config_advert at all.
> That's probably right for ethtool interface, but ethoc doesn't support
> ethtool.
This is not right for libphy either, phydev->supported must reflect
that you support Gigabit or not.
Since ethoc supports libphy, there really is no reason not to
implement the ethtool_{get,set}_settings callbacks using
phy_mii_ioctl().
>
>> device is registered.
>>
>> Rather than poking into the phy_device structure directly from this
>> driver, I think you should add a function in phylib for this purpose.
All drivers are currently modifying phydev->advertising and
phydev->supported directly, most of them do it correctly as far as I
checked. It does make some sense to add a helper function though.
>
> Like below?
>
> ---8<---
> From 347331f399626ecaa9a8e54252f55e0b6788772f Mon Sep 17 00:00:00 2001
> From: Max Filippov <jcmvbkbc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Mon, 27 Jan 2014 04:01:40 +0400
> Subject: [PATCH 1/3] net: ethoc: don't advertise gigabit speed on attached PHY
>
> OpenCores 10/100 Mbps MAC does not support speeds above 100 Mbps, but does
> not disable advertisement when PHY supports them. This results in
> non-functioning network when the MAC is connected to a gigabit PHY connected
> to a gigabit switch.
>
> The fix is to disable gigabit speed advertisement on attached PHY
> unconditionally.
>
> Signed-off-by: Max Filippov <jcmvbkbc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/net/ethernet/ethoc.c | 3 +++
> include/linux/phy.h | 5 +++++
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
> index 4de8cfd..e817d58 100644
> --- a/drivers/net/ethernet/ethoc.c
> +++ b/drivers/net/ethernet/ethoc.c
> @@ -688,6 +688,9 @@ static int ethoc_mdio_probe(struct net_device *dev)
> }
>
> priv->phy = phy;
> + phy_update_adv(phy,
> + ~(ADVERTISED_1000baseT_Full |
> + ADVERTISED_1000baseT_Half), 0);
> return 0;
> }
>
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index 48a4dc3..0282a8d 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -559,6 +559,11 @@ static inline int phy_read_status(struct phy_device *phydev) {
> return phydev->drv->read_status(phydev);
> }
>
> +static inline void phy_update_adv(struct phy_device *phydev, u32 mask, u32 set)
> +{
> + phydev->advertising = (phydev->advertising & mask) | set;
> +}
> +
This should be a preliminary patch to this patchset, so you first
introduce the function, then use it in the driver, but the idea looks
good. There is room for updating quite some drivers out there since
those used to modify phydev->advertising and phydev->supported
directly without using an accessor.
> int genphy_setup_forced(struct phy_device *phydev);
> int genphy_restart_aneg(struct phy_device *phydev);
> int genphy_config_aneg(struct phy_device *phydev);
> --
> 1.8.1.4
>
>
> --
> Thanks.
> -- Max
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V4] regulator: ti-abb: Add support for interleaved LDO registers
From: Mark Brown @ 2014-01-27 19:34 UTC (permalink / raw)
To: Nishanth Menon; +Cc: Liam Girdwood, devicetree, linux-doc, linux-kernel
In-Reply-To: <1390499847-8822-1-git-send-email-nm@ti.com>
[-- Attachment #1: Type: text/plain, Size: 217 bytes --]
On Thu, Jan 23, 2014 at 11:57:27AM -0600, Nishanth Menon wrote:
> Certain platforms such as DRA7 have quirky memory maps such as:
> PRM_ABBLDO_DSPEVE_CTRL 0x4ae07e20
> PRM_ABBLDO_IVA_CTRL 0x4ae07e24
Applied, thanks.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] Binding: atmel-wm8904: add option to choose clock
From: Mark Brown @ 2014-01-27 19:31 UTC (permalink / raw)
To: Bo Shen
Cc: Mark Rutland, devicetree, alsa-devel, linux-doc, Pawel Moll,
Stephen Warren, Ian Campbell, nicolas.ferre, linux-kernel,
linux-sound, Rob Herring, Rob Landley, plagnioj, linux-arm-kernel
In-Reply-To: <1390805726-1841-4-git-send-email-voice.shen@atmel.com>
[-- Attachment #1.1: Type: text/plain, Size: 1117 bytes --]
On Mon, Jan 27, 2014 at 02:55:26PM +0800, Bo Shen wrote:
> diff --git a/Documentation/devicetree/bindings/sound/atmel-wm8904.txt b/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
> index 8bbe50c..2d86e2b 100644
> --- a/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
> +++ b/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
> @@ -33,6 +33,12 @@ Required properties:
>
> Optional properties:
> - pinctrl-names, pinctrl-0: Please refer to pinctrl-bindings.txt
> + - atmel,clk-from-rk-pin: bool property.
> + - When SSC works in slave mode, according to the hardware design, the
> + clock can get from TK pin, and also can get from RK pin. So, add
> + this parameter to choose where the clock from.
> + - By default the clock is from TK pin, if the clock from RK pin, this
> + property is needed.
Can this be made a property of the SSC device so that it's available for
all cards using it rather than just this one? That would also address
the issue with the way the configuration is passed to the controller
that Lars-Peter identified.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH] phy-rcar-usb-gen2: add device tree support
From: Ben Dooks @ 2014-01-27 19:06 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: linux-kernel, linux-usb, linux-sh, Magnus Damm, Simon Horman,
devicetree
In-Reply-To: <52E6A436.5090408@cogentembedded.com>
On 27/01/14 18:23, Sergei Shtylyov wrote:
> Hello.
>
> On 01/26/2014 08:05 PM, Ben Dooks wrote:
[snip]
>>
>> +static struct of_device_id rcar_gen2_usb_phy_ofmatch[] = {
>> + { .compatible = "renesas,usb-phy-r8a7790", },
>> + { .compatible = "renesas,rcar-gen2-usb-phy", },
>
> Frankly speaking, I don't understand the need for the clearly
> duplicate entries.
Thanks, will look into remove it.
Anyone else have any comments on this?
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply
* Re: [PATCH] phy-rcar-usb-gen2: add device tree support
From: Sergei Shtylyov @ 2014-01-27 18:23 UTC (permalink / raw)
To: Ben Dooks, linux-kernel
Cc: linux-usb, linux-sh, Magnus Damm, Simon Horman, devicetree
In-Reply-To: <1390755901-3743-1-git-send-email-ben.dooks@codethink.co.uk>
Hello.
On 01/26/2014 08:05 PM, Ben Dooks wrote:
> Add support for the phy-rcar-gen2-usb driver to be probed from device tree.
> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
> Reviewed-by: Ian Molton <ian.molton@codethink.co.uk>
> ---
> Fixes from v2:
> - fix missing of_if patch
> (I clearly should not be let near git-rebase when hungry)
> Fixes from v1:
> - use of_property_reasd-bool()
> - remove unused of_id variable
> Cc: linux-usb@vger.kernel.org
> Cc: linux-sh@vger.kernel.org
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Simon Horman <horms@verge.net.au>
> Cc: devicetree@vger.kernel.org
> ---
> drivers/usb/phy/phy-rcar-gen2-usb.c | 31 ++++++++++++++++++++++++++-----
> 1 file changed, 26 insertions(+), 5 deletions(-)
> diff --git a/drivers/usb/phy/phy-rcar-gen2-usb.c b/drivers/usb/phy/phy-rcar-gen2-usb.c
> index db3ab34..e4665b9 100644
> --- a/drivers/usb/phy/phy-rcar-gen2-usb.c
> +++ b/drivers/usb/phy/phy-rcar-gen2-usb.c
[...]
> @@ -167,6 +168,12 @@ out:
> spin_unlock_irqrestore(&priv->lock, flags);
> }
>
> +static struct of_device_id rcar_gen2_usb_phy_ofmatch[] = {
> + { .compatible = "renesas,usb-phy-r8a7790", },
> + { .compatible = "renesas,rcar-gen2-usb-phy", },
Frankly speaking, I don't understand the need for the clearly duplicate
entries.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings
From: Lorenzo Pieralisi @ 2014-01-27 18:22 UTC (permalink / raw)
To: Antti P Miettinen
Cc: Mark Rutland, devicetree@vger.kernel.org,
daniel.lezcano@linaro.org, vincent.guittot@linaro.org,
khilman@linaro.org, linux-pm@vger.kernel.org,
pdeschrijver@nvidia.com, nico@linaro.org, sboyd@codeaurora.org,
amit.kucheria@linaro.org, t.figa@samsung.com, robh+dt@kernel.org,
santosh.shilimkar@ti.com, hanjun.guo@linaro.org,
mark.hambleton@broadcom.com, Sudeep Holla,
grant.likely@linaro.org, galak@codeaurora.org
In-Reply-To: <20140127.144815.1048814583962628826.apm@brigitte.kvy.fi>
On Mon, Jan 27, 2014 at 12:48:15PM +0000, Antti P Miettinen wrote:
> From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > That's why I defined the worst case. How did you implemented it in your
> > idle drivers ? That would help generalize it, after all these bindings
> > are there to simplify drivers upstreaming, feedback welcome.
>
> Currently we do not handle this well downstream either. The problem
> with worst case is that the absolute worst case can be really bad and
> probability of it might be very low. Sorry - no ready answer :-)
Point taken, but these bindings still get us to a point that is much
better than today situation. After all, if the worst case can happen
either we design for worst case or we update parameters at runtime in
the kernel (which is not happening as of now) according to a notification
mechanism.
It is certainly worth investigating, probably we can define OPPs as
generic (ie not tied to the CPU), as performance point or system
operating points. I will think about this.
In the meantime if you have further pieces of feedback please keep them
coming.
Thanks,
Lorenzo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox