* Re: [RFC PATCH 3/9] of: mtd: add NAND timings retrieval support
From: Grant Likely @ 2014-02-04 17:02 UTC (permalink / raw)
To: Jason Gunthorpe, boris brezillon
Cc: devicetree, Russell King, linux-doc, dev, linux-kernel, linux-mtd,
Rob Landley, Maxime Ripard, David Woodhouse, linux-arm-kernel
In-Reply-To: <20140121225740.GP18269@obsidianresearch.com>
On Tue, 21 Jan 2014 15:57:40 -0700, Jason Gunthorpe <jgunthorpe@obsidianresearch.com> wrote:
> On Wed, Jan 15, 2014 at 06:03:01PM +0100, boris brezillon wrote:
>
> > >>Pick a mode value that fits all the parameters of the connected
> > >>non-ONFI flash.
> > >>
> > >>This would be instead of defining each parameter
> > >>individually.. Provide some helpers to convert from a onfi mode number
> > >>to all the onfi defined timing parameters so that drivers can
> > >>configure the HW..
> > >
> > >Are you suggesting we should provide a function that converts these
> > >modes into a nand_timings struct, or just use the timing modes and
> > >let the NAND controller drivers configure its IP accordingly ?
>
> Either seems reasonable to me, but passing the ONFI mode directly from
> the NAND core to the driver seems a little safer..
I agree here. There are a lot of parameters being defined. If it can be
boiled down to an ONFI mode that will make for a much more robust
binding. Far fewer things to get wrong.
g.
^ permalink raw reply
* Re: [PATCH 3/6] mfd: add bcm59056 pmu driver
From: Lee Jones @ 2014-02-04 17:08 UTC (permalink / raw)
To: Mark Brown
Cc: Matt Porter, Wolfram Sang, Tim Kryger, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Samuel Ortiz,
Liam Girdwood, Christian Daudt, Devicetree List, Linux I2C List,
Linux ARM Kernel List, Linux Kernel Mailing List
In-Reply-To: <20140204165906.GC22609@sirena.org.uk>
> > > > +static struct i2c_driver bcm59056_i2c_driver = {
> > > > + .driver = {
> > > > + .name = "bcm59056",
> > > > + .owner = THIS_MODULE,
> > > > + .of_match_table = of_match_ptr(bcm59056_of_match),
>
> > > No need to use of_match_ptr() here.
>
> > Will remove.
>
> What using of_match_ptr() should do is allow the compiler to figure out
> that the table isn't used when DT is disabled and discard it without
> ifdefs. Not sure if that actually works yet but that's the idea.
Right, but I'm guessing that as there is no support for platform data
then this device(s) is going to be DT only? If that's the case perhaps
a 'depends OF' might be in order. If that's not the case then I'm more
than happy to leave the of_match_ptr() in.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH net-next 2/2] stmmac: add extended set multicast filter & devicetree options
From: Vince Bridgers @ 2014-02-04 17:10 UTC (permalink / raw)
To: Giuseppe CAVALLARO
Cc: devicetree, netdev, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, Kumar Gala, Dinh Nguyen, Rayagond Kokatanur
In-Reply-To: <52F0B99E.6090302@st.com>
On Tue, Feb 4, 2014 at 3:57 AM, Giuseppe CAVALLARO
<peppe.cavallaro@st.com> wrote:
> On 1/31/2014 9:15 PM, Vince Bridgers wrote:
>>
>> The synopsys EMAC can be configured for different numbers of multicast
>> hash
>> bins and perfect filter entries at device creation time and there's no way
>> to query this configuration information at runtime. As a result, a
>> devicetree
>> parameter is required in order for the driver to program these filters
>> correctly for a particular device instance. This patch extends the current
>> driver by providing a different multicast filter programming function if
>> different than the currently supported 64 multicast hash bins and 32
>> perfect unicast addresses. This patch is required to correct multicast
>> filtering for the Altera Cyclone V SOC.
>>
>> Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com>
>> ---
>> drivers/net/ethernet/stmicro/stmmac/common.h | 42 +++--
>> drivers/net/ethernet/stmicro/stmmac/dwmac1000.h | 5 +-
>> .../net/ethernet/stmicro/stmmac/dwmac1000_core.c | 161
>> +++++++++++++++++---
>> .../net/ethernet/stmicro/stmmac/dwmac100_core.c | 29 ++--
>> .../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 6 +-
>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 36 ++---
>> .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 51 +++++++
>> include/linux/stmmac.h | 2 +
>> 8 files changed, 261 insertions(+), 71 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
>> b/drivers/net/ethernet/stmicro/stmmac/common.h
>> index 7834a39..ca07afe 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/common.h
>> +++ b/drivers/net/ethernet/stmicro/stmmac/common.h
>> @@ -294,6 +294,8 @@ struct dma_features {
>>
>> #define JUMBO_LEN 9000
>>
>> +#define GMAC_MAX_PERFECT_ADDRESSES 32
>> +
>> struct stmmac_desc_ops {
>> /* DMA RX descriptor ring initialization */
>> void (*init_rx_desc) (struct dma_desc *p, int disable_rx_ic, int
>> mode,
>> @@ -368,34 +370,37 @@ struct stmmac_dma_ops {
>> void (*rx_watchdog) (void __iomem *ioaddr, u32 riwt);
>> };
>>
>> +struct mac_device_info;
>> +
>> struct stmmac_ops {
>> /* MAC core initialization */
>> - void (*core_init) (void __iomem *ioaddr, int mtu);
>> + void (*core_init)(struct mac_device_info *hw, int mtu);
>> /* Enable and verify that the IPC module is supported */
>> - int (*rx_ipc) (void __iomem *ioaddr);
>> + int (*rx_ipc)(struct mac_device_info *hw);
>> /* Dump MAC registers */
>> - void (*dump_regs) (void __iomem *ioaddr);
>> + void (*dump_regs)(struct mac_device_info *hw);
>> /* Handle extra events on specific interrupts hw dependent */
>> - int (*host_irq_status) (void __iomem *ioaddr,
>> + int (*host_irq_status)(struct mac_device_info *hw,
>> struct stmmac_extra_stats *x);
>> /* Multicast filter setting */
>> - void (*set_filter) (struct net_device *dev, int id);
>> + void (*set_filter)(struct mac_device_info *hw,
>> + struct net_device *dev);
>> /* Flow control setting */
>> - void (*flow_ctrl) (void __iomem *ioaddr, unsigned int duplex,
>> + void (*flow_ctrl)(struct mac_device_info *hw, unsigned int duplex,
>> unsigned int fc, unsigned int pause_time);
>> /* Set power management mode (e.g. magic frame) */
>> - void (*pmt) (void __iomem *ioaddr, unsigned long mode);
>> + void (*pmt)(struct mac_device_info *hw, unsigned long mode);
>> /* Set/Get Unicast MAC addresses */
>> - void (*set_umac_addr) (void __iomem *ioaddr, unsigned char *addr,
>> + void (*set_umac_addr)(struct mac_device_info *hw, unsigned char
>> *addr,
>> unsigned int reg_n);
>> - void (*get_umac_addr) (void __iomem *ioaddr, unsigned char *addr,
>> + void (*get_umac_addr)(struct mac_device_info *hw, unsigned char
>> *addr,
>> unsigned int reg_n);
>> - void (*set_eee_mode) (void __iomem *ioaddr);
>> - void (*reset_eee_mode) (void __iomem *ioaddr);
>> - void (*set_eee_timer) (void __iomem *ioaddr, int ls, int tw);
>> - void (*set_eee_pls) (void __iomem *ioaddr, int link);
>> - void (*ctrl_ane) (void __iomem *ioaddr, bool restart);
>> - void (*get_adv) (void __iomem *ioaddr, struct rgmii_adv *adv);
>> + void (*set_eee_mode)(struct mac_device_info *hw);
>> + void (*reset_eee_mode)(struct mac_device_info *hw);
>> + void (*set_eee_timer)(struct mac_device_info *hw, int ls, int tw);
>> + void (*set_eee_pls)(struct mac_device_info *hw, int link);
>> + void (*ctrl_ane)(struct mac_device_info *hw, bool restart);
>> + void (*get_adv)(struct mac_device_info *hw, struct rgmii_adv
>> *adv);
>> };
>>
>> struct stmmac_hwtimestamp {
>> @@ -447,9 +452,14 @@ struct mac_device_info {
>> struct mii_regs mii; /* MII register Addresses */
>> struct mac_link link;
>> unsigned int synopsys_uid;
>> + void __iomem *pcsr; /* vpointer to device CSRs */
>> + int multicast_filter_bins;
>> + int unicast_filter_entries;
>> + int mcast_bits_log2;
>> };
>>
>> -struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr);
>> +struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr,
>> + int mcbins, int
>> perfect_uc_entries);
>> struct mac_device_info *dwmac100_setup(void __iomem *ioaddr);
>>
>> void stmmac_set_mac_addr(void __iomem *ioaddr, u8 addr[6],
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
>> b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
>> index f37d90f..40b8533 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
>> @@ -87,7 +87,6 @@ enum power_event {
>> (reg * 8))
>> #define GMAC_ADDR_LOW(reg) (((reg > 15) ? 0x00000804 : 0x00000044) +
>> \
>> (reg * 8))
>> -#define GMAC_MAX_PERFECT_ADDRESSES 32
>>
>> /* PCS registers (AN/TBI/SGMII/RGMII) offset */
>> #define GMAC_AN_CTRL 0x000000c0 /* AN control */
>> @@ -130,6 +129,8 @@ enum power_event {
>> #define GMAC_CONTROL_2K 0x08000000 /* IEEE 802.3as 2K packets */
>> #define GMAC_CONTROL_TC 0x01000000 /* Transmit Conf. in
>> RGMII/SGMII */
>> #define GMAC_CONTROL_WD 0x00800000 /* Disable Watchdog on
>> receive */
>> +
>> +/* GMAC Configuration defines */
>> #define GMAC_CONTROL_JD 0x00400000 /* Jabber disable */
>> #define GMAC_CONTROL_BE 0x00200000 /* Frame Burst Enable */
>> #define GMAC_CONTROL_JE 0x00100000 /* Jumbo frame */
>> @@ -262,5 +263,7 @@ enum rtc_control {
>> #define GMAC_MMC_TX_INTR 0x108
>> #define GMAC_MMC_RX_CSUM_OFFLOAD 0x208
>>
>> +#define GMAC_EXTHASH_BASE 0x500
>> +
>> extern const struct stmmac_dma_ops dwmac1000_dma_ops;
>> #endif /* __DWMAC1000_H__ */
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>> b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>> index b3e148e..44db9fb 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
>> @@ -26,14 +26,15 @@
>> Author: Giuseppe Cavallaro <peppe.cavallaro@st.com>
>>
>> *******************************************************************************/
>>
>> +#include <linux/io.h>
>> #include <linux/crc32.h>
>> -#include <linux/slab.h>
>> #include <linux/ethtool.h>
>> -#include <asm/io.h>
>> +#include <linux/slab.h>
>> #include "dwmac1000.h"
>>
>> -static void dwmac1000_core_init(void __iomem *ioaddr, int mtu)
>> +static void dwmac1000_core_init(struct mac_device_info *hw, int mtu)
>> {
>> + void __iomem *ioaddr = hw->pcsr;
>> u32 value = readl(ioaddr + GMAC_CONTROL);
>> value |= GMAC_CORE_INIT;
>> if (mtu > 1500)
>> @@ -52,8 +53,9 @@ static void dwmac1000_core_init(void __iomem *ioaddr,
>> int mtu)
>> #endif
>> }
>>
>> -static int dwmac1000_rx_ipc_enable(void __iomem *ioaddr)
>> +static int dwmac1000_rx_ipc_enable(struct mac_device_info *hw)
>> {
>> + void __iomem *ioaddr = hw->pcsr;
>> u32 value = readl(ioaddr + GMAC_CONTROL);
>>
>> value |= GMAC_CONTROL_IPC;
>> @@ -64,8 +66,9 @@ static int dwmac1000_rx_ipc_enable(void __iomem *ioaddr)
>> return !!(value & GMAC_CONTROL_IPC);
>> }
>>
>> -static void dwmac1000_dump_regs(void __iomem *ioaddr)
>> +static void dwmac1000_dump_regs(struct mac_device_info *hw)
>> {
>> + void __iomem *ioaddr = hw->pcsr;
>> int i;
>> pr_info("\tDWMAC1000 regs (base addr = 0x%p)\n", ioaddr);
>>
>> @@ -76,21 +79,113 @@ static void dwmac1000_dump_regs(void __iomem *ioaddr)
>> }
>> }
>>
>> -static void dwmac1000_set_umac_addr(void __iomem *ioaddr, unsigned char
>> *addr,
>> +static void dwmac1000_set_umac_addr(struct mac_device_info *hw,
>> + unsigned char *addr,
>> unsigned int reg_n)
>> {
>> - stmmac_set_mac_addr(ioaddr, addr, GMAC_ADDR_HIGH(reg_n),
>> + stmmac_set_mac_addr(hw->pcsr, addr, GMAC_ADDR_HIGH(reg_n),
>> GMAC_ADDR_LOW(reg_n));
>> }
>>
>> -static void dwmac1000_get_umac_addr(void __iomem *ioaddr, unsigned char
>> *addr,
>> +static void dwmac1000_get_umac_addr(struct mac_device_info *hw,
>> + unsigned char *addr,
>> unsigned int reg_n)
>> {
>> - stmmac_get_mac_addr(ioaddr, addr, GMAC_ADDR_HIGH(reg_n),
>> + stmmac_get_mac_addr(hw->pcsr, addr, GMAC_ADDR_HIGH(reg_n),
>> GMAC_ADDR_LOW(reg_n));
>> }
>>
>> -static void dwmac1000_set_filter(struct net_device *dev, int id)
>> +static void dwmac1000_set_extmchash(void __iomem *ioaddr, u32
>> *mcfilterbits,
>> + int numhashregs)
>> +{
>> + int regs;
>> + for (regs = 0; regs < numhashregs; regs++)
>> + writel(mcfilterbits[regs],
>> + ioaddr + GMAC_EXTHASH_BASE + regs * 4);
>> +}
>> +
>> +static void dwmac1000_set_filterex(struct mac_device_info *hw,
>> + struct net_device *dev)
>> +{
>> + void __iomem *ioaddr = (void __iomem *)dev->base_addr;
>> + unsigned int value = 0;
>> + unsigned int perfect_addr_number;
>> + u32 mc_filter[8];
>> +
>> + pr_debug("%s: # mcasts %d, # unicast %d\n", __func__,
>> + netdev_mc_count(dev), netdev_uc_count(dev));
>> +
>> + if (dev->flags & IFF_PROMISC) {
>> + value = GMAC_FRAME_FILTER_PR;
>> + } else if (dev->flags & IFF_ALLMULTI) {
>> + value = GMAC_FRAME_FILTER_PM; /* pass all multi */
>> + } else if (!netdev_mc_empty(dev)) {
>> + struct netdev_hw_addr *ha;
>> +
>> + memset(mc_filter, 0, sizeof(mc_filter));
>> +
>> + /* Hash filter for multicast */
>> + value = GMAC_FRAME_FILTER_HMC;
>> +
>> + netdev_for_each_mc_addr(ha, dev) {
>> + /* The upper n bits of the calculated CRC are used
>> to
>> + * index the contents of the hash table depending
>> + * on the particular core's multicast hash size
>> + * configured through Synopsys Core Consultant
>> + */
>> + int bit_nr = bitrev32(~crc32_le(~0, ha->addr,
>> + ETH_ALEN)) >>
>> + (32 - hw->mcast_bits_log2);
>> +
>> + /* The most significant bit determines the
>> register to
>> + * use (H/L) while the other 5 bits determine the
>> bit
>> + * within the register.
>> + */
>> + mc_filter[bit_nr >> 5] |= 1 << (bit_nr & 31);
>> + }
>> + if (hw->mcast_bits_log2 == 6) {
>> + writel(mc_filter[0], ioaddr + GMAC_HASH_LOW);
>> + writel(mc_filter[1], ioaddr + GMAC_HASH_HIGH);
>> + } else if (hw->mcast_bits_log2 == 7) {
>> + dwmac1000_set_extmchash(ioaddr, mc_filter, 4);
>> + } else if (hw->mcast_bits_log2 == 8) {
>> + dwmac1000_set_extmchash(ioaddr, mc_filter, 8);
>> + } else {
>> + pr_debug("STMMAC: err in setting mulitcast
>> filter\n");
>> + }
>> + }
>> +
>> + /* Extra 16 regs are available in cores newer than the 3.40. */
>> + if (hw->synopsys_uid > DWMAC_CORE_3_40)
>> + perfect_addr_number = hw->unicast_filter_entries;
>> + else
>> + perfect_addr_number = hw->unicast_filter_entries / 2;
>
>
> can you check if this is safe enough? I mean if we pass a setting that
> could generate problems in case of old Synopsys chips.
I was going by the existing code and what I could get out of the
Synopsys 10/100/1000 DwMAC Databook, but will check with Synopsys to
verify what I believe to be true. I posted a support request to
Synopsys asking for the best way to know about the number of available
unicast filter entries by the core version number and copied you on
the request. I'll be sure to forward any valuable technical
information from the conversation, and update the code accordingly
with my next submission.
>
>
>> +
>> + /* Handle multiple unicast addresses (perfect filtering) */
>> + if (netdev_uc_count(dev) > perfect_addr_number)
>> + /* Switch to promiscuous mode if more than 16 addrs
>> + * are required
>> + */
>> + value |= GMAC_FRAME_FILTER_PR;
>> + else {
>> + int reg = 1;
>> + struct netdev_hw_addr *ha;
>> +
>> + netdev_for_each_uc_addr(ha, dev) {
>> + dwmac1000_set_umac_addr(hw, ha->addr, reg);
>> + reg++;
>> + }
>> + }
>> +
>> +#ifdef FRAME_FILTER_DEBUG
>> + /* Enable Receive all mode (to debug filtering_fail errors) */
>> + value |= GMAC_FRAME_FILTER_RA;
>> +#endif
>> + writel(value, ioaddr + GMAC_FRAME_FILTER);
>> +}
>> +
>> +static void dwmac1000_set_filter(struct mac_device_info *hw,
>> + struct net_device *dev)
>> {
>> void __iomem *ioaddr = (void __iomem *)dev->base_addr;
>> unsigned int value = 0;
>> @@ -130,7 +225,7 @@ static void dwmac1000_set_filter(struct net_device
>> *dev, int id)
>> }
>>
>> /* Extra 16 regs are available in cores newer than the 3.40. */
>> - if (id > DWMAC_CORE_3_40)
>> + if (hw->synopsys_uid > DWMAC_CORE_3_40)
>> perfect_addr_number = GMAC_MAX_PERFECT_ADDRESSES;
>> else
>> perfect_addr_number = GMAC_MAX_PERFECT_ADDRESSES / 2;
>> @@ -146,7 +241,7 @@ static void dwmac1000_set_filter(struct net_device
>> *dev, int id)
>> struct netdev_hw_addr *ha;
>>
>> netdev_for_each_uc_addr(ha, dev) {
>> - dwmac1000_set_umac_addr(ioaddr, ha->addr, reg);
>> + dwmac1000_set_umac_addr(hw, ha->addr, reg);
>> reg++;
>> }
>> }
>> @@ -162,9 +257,10 @@ static void dwmac1000_set_filter(struct net_device
>> *dev, int id)
>> readl(ioaddr + GMAC_HASH_HIGH), readl(ioaddr +
>> GMAC_HASH_LOW));
>> }
>>
>> -static void dwmac1000_flow_ctrl(void __iomem *ioaddr, unsigned int
>> duplex,
>> +static void dwmac1000_flow_ctrl(struct mac_device_info *hw, unsigned int
>> duplex,
>> unsigned int fc, unsigned int pause_time)
>> {
>> + void __iomem *ioaddr = hw->pcsr;
>> unsigned int flow = 0;
>>
>> pr_debug("GMAC Flow-Control:\n");
>> @@ -185,8 +281,9 @@ static void dwmac1000_flow_ctrl(void __iomem *ioaddr,
>> unsigned int duplex,
>> writel(flow, ioaddr + GMAC_FLOW_CTRL);
>> }
>>
>> -static void dwmac1000_pmt(void __iomem *ioaddr, unsigned long mode)
>> +static void dwmac1000_pmt(struct mac_device_info *hw, unsigned long mode)
>> {
>> + void __iomem *ioaddr = hw->pcsr;
>> unsigned int pmt = 0;
>>
>> if (mode & WAKE_MAGIC) {
>> @@ -201,9 +298,10 @@ static void dwmac1000_pmt(void __iomem *ioaddr,
>> unsigned long mode)
>> writel(pmt, ioaddr + GMAC_PMT);
>> }
>>
>> -static int dwmac1000_irq_status(void __iomem *ioaddr,
>> +static int dwmac1000_irq_status(struct mac_device_info *hw,
>> struct stmmac_extra_stats *x)
>> {
>> + void __iomem *ioaddr = hw->pcsr;
>> u32 intr_status = readl(ioaddr + GMAC_INT_STATUS);
>> int ret = 0;
>>
>> @@ -268,8 +366,9 @@ static int dwmac1000_irq_status(void __iomem *ioaddr,
>> return ret;
>> }
>>
>> -static void dwmac1000_set_eee_mode(void __iomem *ioaddr)
>> +static void dwmac1000_set_eee_mode(struct mac_device_info *hw)
>> {
>> + void __iomem *ioaddr = hw->pcsr;
>> u32 value;
>>
>> /* Enable the link status receive on RGMII, SGMII ore SMII
>> @@ -281,8 +380,9 @@ static void dwmac1000_set_eee_mode(void __iomem
>> *ioaddr)
>> writel(value, ioaddr + LPI_CTRL_STATUS);
>> }
>>
>> -static void dwmac1000_reset_eee_mode(void __iomem *ioaddr)
>> +static void dwmac1000_reset_eee_mode(struct mac_device_info *hw)
>> {
>> + void __iomem *ioaddr = hw->pcsr;
>> u32 value;
>>
>> value = readl(ioaddr + LPI_CTRL_STATUS);
>> @@ -290,8 +390,9 @@ static void dwmac1000_reset_eee_mode(void __iomem
>> *ioaddr)
>> writel(value, ioaddr + LPI_CTRL_STATUS);
>> }
>>
>> -static void dwmac1000_set_eee_pls(void __iomem *ioaddr, int link)
>> +static void dwmac1000_set_eee_pls(struct mac_device_info *hw, int link)
>> {
>> + void __iomem *ioaddr = hw->pcsr;
>> u32 value;
>>
>> value = readl(ioaddr + LPI_CTRL_STATUS);
>> @@ -304,8 +405,9 @@ static void dwmac1000_set_eee_pls(void __iomem
>> *ioaddr, int link)
>> writel(value, ioaddr + LPI_CTRL_STATUS);
>> }
>>
>> -static void dwmac1000_set_eee_timer(void __iomem *ioaddr, int ls, int tw)
>> +static void dwmac1000_set_eee_timer(struct mac_device_info *hw, int ls,
>> int tw)
>> {
>> + void __iomem *ioaddr = hw->pcsr;
>> int value = ((tw & 0xffff)) | ((ls & 0x7ff) << 16);
>>
>> /* Program the timers in the LPI timer control register:
>> @@ -318,8 +420,9 @@ static void dwmac1000_set_eee_timer(void __iomem
>> *ioaddr, int ls, int tw)
>> writel(value, ioaddr + LPI_TIMER_CTRL);
>> }
>>
>> -static void dwmac1000_ctrl_ane(void __iomem *ioaddr, bool restart)
>> +static void dwmac1000_ctrl_ane(struct mac_device_info *hw, bool restart)
>> {
>> + void __iomem *ioaddr = hw->pcsr;
>> u32 value;
>>
>> value = readl(ioaddr + GMAC_AN_CTRL);
>> @@ -332,8 +435,9 @@ static void dwmac1000_ctrl_ane(void __iomem *ioaddr,
>> bool restart)
>> writel(value, ioaddr + GMAC_AN_CTRL);
>> }
>>
>> -static void dwmac1000_get_adv(void __iomem *ioaddr, struct rgmii_adv
>> *adv)
>> +static void dwmac1000_get_adv(struct mac_device_info *hw, struct
>> rgmii_adv *adv)
>> {
>> + void __iomem *ioaddr = hw->pcsr;
>> u32 value = readl(ioaddr + GMAC_ANE_ADV);
>>
>> if (value & GMAC_ANE_FD)
>> @@ -353,7 +457,7 @@ static void dwmac1000_get_adv(void __iomem *ioaddr,
>> struct rgmii_adv *adv)
>> adv->lp_pause = (value & GMAC_ANE_PSE) >> GMAC_ANE_PSE_SHIFT;
>> }
>>
>> -static const struct stmmac_ops dwmac1000_ops = {
>> +static struct stmmac_ops dwmac1000_ops = {
>> .core_init = dwmac1000_core_init,
>> .rx_ipc = dwmac1000_rx_ipc_enable,
>> .dump_regs = dwmac1000_dump_regs,
>> @@ -371,7 +475,8 @@ static const struct stmmac_ops dwmac1000_ops = {
>> .get_adv = dwmac1000_get_adv,
>> };
>>
>> -struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr)
>> +struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr, int mcbins,
>> + int perfect_uc_entries)
>> {
>> struct mac_device_info *mac;
>> u32 hwid = readl(ioaddr + GMAC_VERSION);
>> @@ -380,6 +485,16 @@ struct mac_device_info *dwmac1000_setup(void __iomem
>> *ioaddr)
>> if (!mac)
>> return NULL;
>>
>> + mac->pcsr = ioaddr;
>> + mac->multicast_filter_bins = mcbins;
>> + mac->unicast_filter_entries = perfect_uc_entries;
>> + mac->mcast_bits_log2 = 0;
>> + if (mac->multicast_filter_bins)
>> + mac->mcast_bits_log2 = ilog2(mac->multicast_filter_bins);
>> +
>> + if (mac->mcast_bits_log2 != 64)
>> + dwmac1000_ops.set_filter = dwmac1000_set_filterex;
>> +
>> mac->mac = &dwmac1000_ops;
>> mac->dma = &dwmac1000_dma_ops;
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
>> b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
>> index 2ff767b..3ee3ab5 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
>> @@ -28,12 +28,13 @@
>> Author: Giuseppe Cavallaro <peppe.cavallaro@st.com>
>>
>> *******************************************************************************/
>>
>> -#include <linux/crc32.h>
>> #include <asm/io.h>
>> +#include <linux/crc32.h>
>> #include "dwmac100.h"
>>
>> -static void dwmac100_core_init(void __iomem *ioaddr, int mtu)
>> +static void dwmac100_core_init(struct mac_device_info *hw, int mtu)
>> {
>> + void __iomem *ioaddr = hw->pcsr;
>> u32 value = readl(ioaddr + MAC_CONTROL);
>>
>> writel((value | MAC_CORE_INIT), ioaddr + MAC_CONTROL);
>> @@ -43,8 +44,9 @@ static void dwmac100_core_init(void __iomem *ioaddr, int
>> mtu)
>> #endif
>> }
>>
>> -static void dwmac100_dump_mac_regs(void __iomem *ioaddr)
>> +static void dwmac100_dump_mac_regs(struct mac_device_info *hw)
>> {
>> + void __iomem *ioaddr = hw->pcsr;
>> pr_info("\t----------------------------------------------\n"
>> "\t DWMAC 100 CSR (base addr = 0x%p)\n"
>> "\t----------------------------------------------\n",
>> ioaddr);
>> @@ -66,30 +68,35 @@ static void dwmac100_dump_mac_regs(void __iomem
>> *ioaddr)
>> readl(ioaddr + MAC_VLAN2));
>> }
>>
>> -static int dwmac100_rx_ipc_enable(void __iomem *ioaddr)
>> +static int dwmac100_rx_ipc_enable(struct mac_device_info *hw)
>> {
>> return 0;
>> }
>>
>> -static int dwmac100_irq_status(void __iomem *ioaddr,
>> +static int dwmac100_irq_status(struct mac_device_info *hw,
>> struct stmmac_extra_stats *x)
>> {
>> return 0;
>> }
>>
>> -static void dwmac100_set_umac_addr(void __iomem *ioaddr, unsigned char
>> *addr,
>> +static void dwmac100_set_umac_addr(struct mac_device_info *hw,
>> + unsigned char *addr,
>> unsigned int reg_n)
>> {
>> + void __iomem *ioaddr = hw->pcsr;
>> stmmac_set_mac_addr(ioaddr, addr, MAC_ADDR_HIGH, MAC_ADDR_LOW);
>> }
>>
>> -static void dwmac100_get_umac_addr(void __iomem *ioaddr, unsigned char
>> *addr,
>> +static void dwmac100_get_umac_addr(struct mac_device_info *hw,
>> + unsigned char *addr,
>> unsigned int reg_n)
>> {
>> + void __iomem *ioaddr = hw->pcsr;
>> stmmac_get_mac_addr(ioaddr, addr, MAC_ADDR_HIGH, MAC_ADDR_LOW);
>> }
>>
>> -static void dwmac100_set_filter(struct net_device *dev, int id)
>> +static void dwmac100_set_filter(struct mac_device_info *hw,
>> + struct net_device *dev)
>> {
>> void __iomem *ioaddr = (void __iomem *)dev->base_addr;
>> u32 value = readl(ioaddr + MAC_CONTROL);
>> @@ -137,9 +144,10 @@ static void dwmac100_set_filter(struct net_device
>> *dev, int id)
>> writel(value, ioaddr + MAC_CONTROL);
>> }
>>
>> -static void dwmac100_flow_ctrl(void __iomem *ioaddr, unsigned int duplex,
>> +static void dwmac100_flow_ctrl(struct mac_device_info *hw, unsigned int
>> duplex,
>> unsigned int fc, unsigned int pause_time)
>> {
>> + void __iomem *ioaddr = hw->pcsr;
>> unsigned int flow = MAC_FLOW_CTRL_ENABLE;
>>
>> if (duplex)
>> @@ -148,7 +156,7 @@ static void dwmac100_flow_ctrl(void __iomem *ioaddr,
>> unsigned int duplex,
>> }
>>
>> /* No PMT module supported on ST boards with this Eth chip. */
>> -static void dwmac100_pmt(void __iomem *ioaddr, unsigned long mode)
>> +static void dwmac100_pmt(struct mac_device_info *hw, unsigned long mode)
>> {
>> return;
>> }
>> @@ -175,6 +183,7 @@ struct mac_device_info *dwmac100_setup(void __iomem
>> *ioaddr)
>>
>> pr_info("\tDWMAC100\n");
>>
>> + mac->pcsr = ioaddr;
>> mac->mac = &dwmac100_ops;
>> mac->dma = &dwmac100_dma_ops;
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
>> index c5f9cb8..e679fa6 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
>> @@ -262,7 +262,7 @@ static int stmmac_ethtool_getsettings(struct
>> net_device *dev,
>>
>> /* Get and convert ADV/LP_ADV from the HW AN registers */
>> if (priv->hw->mac->get_adv)
>> - priv->hw->mac->get_adv(priv->ioaddr, &adv);
>> + priv->hw->mac->get_adv(priv->hw, &adv);
>> else
>> return -EOPNOTSUPP; /* should never happen
>> indeed */
>>
>> @@ -352,7 +352,7 @@ static int stmmac_ethtool_setsettings(struct
>> net_device *dev,
>>
>> spin_lock(&priv->lock);
>> if (priv->hw->mac->ctrl_ane)
>> - priv->hw->mac->ctrl_ane(priv->ioaddr, 1);
>> + priv->hw->mac->ctrl_ane(priv->hw, 1);
>> spin_unlock(&priv->lock);
>> }
>>
>> @@ -471,7 +471,7 @@ stmmac_set_pauseparam(struct net_device *netdev,
>> if (netif_running(netdev))
>> ret = phy_start_aneg(phy);
>> } else
>> - priv->hw->mac->flow_ctrl(priv->ioaddr, phy->duplex,
>> + priv->hw->mac->flow_ctrl(priv->hw, phy->duplex,
>> priv->flow_ctrl, priv->pause);
>> spin_unlock(&priv->lock);
>> return ret;
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> index d93aa87..aaa14b2 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>> @@ -233,7 +233,7 @@ static void stmmac_enable_eee_mode(struct stmmac_priv
>> *priv)
>> /* Check and enter in LPI mode */
>> if ((priv->dirty_tx == priv->cur_tx) &&
>> (priv->tx_path_in_lpi_mode == false))
>> - priv->hw->mac->set_eee_mode(priv->ioaddr);
>> + priv->hw->mac->set_eee_mode(priv->hw);
>> }
>>
>> /**
>> @@ -244,7 +244,7 @@ static void stmmac_enable_eee_mode(struct stmmac_priv
>> *priv)
>> */
>> void stmmac_disable_eee_mode(struct stmmac_priv *priv)
>> {
>> - priv->hw->mac->reset_eee_mode(priv->ioaddr);
>> + priv->hw->mac->reset_eee_mode(priv->hw);
>> del_timer_sync(&priv->eee_ctrl_timer);
>> priv->tx_path_in_lpi_mode = false;
>> }
>> @@ -298,12 +298,12 @@ bool stmmac_eee_init(struct stmmac_priv *priv)
>> priv->eee_ctrl_timer.expires =
>> STMMAC_LPI_T(eee_timer);
>> add_timer(&priv->eee_ctrl_timer);
>>
>> - priv->hw->mac->set_eee_timer(priv->ioaddr,
>> + priv->hw->mac->set_eee_timer(priv->hw,
>>
>> STMMAC_DEFAULT_LIT_LS,
>> priv->tx_lpi_timer);
>> } else
>> /* Set HW EEE according to the speed */
>> - priv->hw->mac->set_eee_pls(priv->ioaddr,
>> + priv->hw->mac->set_eee_pls(priv->hw,
>> priv->phydev->link);
>>
>> pr_info("stmmac: Energy-Efficient Ethernet
>> initialized\n");
>> @@ -678,7 +678,7 @@ static void stmmac_adjust_link(struct net_device *dev)
>> }
>> /* Flow Control operation */
>> if (phydev->pause)
>> - priv->hw->mac->flow_ctrl(priv->ioaddr,
>> phydev->duplex,
>> + priv->hw->mac->flow_ctrl(priv->hw, phydev->duplex,
>> fc, pause_time);
>>
>> if (phydev->speed != priv->speed) {
>> @@ -1519,8 +1519,7 @@ static int stmmac_get_hw_features(struct stmmac_priv
>> *priv)
>> static void stmmac_check_ether_addr(struct stmmac_priv *priv)
>> {
>> if (!is_valid_ether_addr(priv->dev->dev_addr)) {
>> - priv->hw->mac->get_umac_addr((void __iomem *)
>> - priv->dev->base_addr,
>> + priv->hw->mac->get_umac_addr(priv->hw,
>> priv->dev->dev_addr, 0);
>> if (!is_valid_ether_addr(priv->dev->dev_addr))
>> eth_hw_addr_random(priv->dev);
>> @@ -1617,14 +1616,14 @@ static int stmmac_hw_setup(struct net_device *dev)
>> }
>>
>> /* Copy the MAC addr into the HW */
>> - priv->hw->mac->set_umac_addr(priv->ioaddr, dev->dev_addr, 0);
>> + priv->hw->mac->set_umac_addr(priv->hw, dev->dev_addr, 0);
>>
>> /* If required, perform hw setup of the bus. */
>> if (priv->plat->bus_setup)
>> priv->plat->bus_setup(priv->ioaddr);
>>
>> /* Initialize the MAC Core */
>> - priv->hw->mac->core_init(priv->ioaddr, dev->mtu);
>> + priv->hw->mac->core_init(priv->hw, dev->mtu);
>>
>> /* Enable the MAC Rx/Tx */
>> stmmac_set_mac(priv->ioaddr, true);
>> @@ -1650,7 +1649,7 @@ static int stmmac_hw_setup(struct net_device *dev)
>>
>> /* Dump DMA/MAC registers */
>> if (netif_msg_hw(priv)) {
>> - priv->hw->mac->dump_regs(priv->ioaddr);
>> + priv->hw->mac->dump_regs(priv->hw);
>> priv->hw->dma->dump_regs(priv->ioaddr);
>> }
>> priv->tx_lpi_timer = STMMAC_DEFAULT_TWT_LS;
>> @@ -1665,7 +1664,7 @@ static int stmmac_hw_setup(struct net_device *dev)
>> }
>>
>> if (priv->pcs && priv->hw->mac->ctrl_ane)
>> - priv->hw->mac->ctrl_ane(priv->ioaddr, 0);
>> + priv->hw->mac->ctrl_ane(priv->hw, 0);
>>
>> return 0;
>> }
>> @@ -2244,7 +2243,7 @@ static void stmmac_set_rx_mode(struct net_device
>> *dev)
>> struct stmmac_priv *priv = netdev_priv(dev);
>>
>> spin_lock(&priv->lock);
>> - priv->hw->mac->set_filter(dev, priv->synopsys_id);
>> + priv->hw->mac->set_filter(priv->hw, dev);
>> spin_unlock(&priv->lock);
>> }
>>
>> @@ -2334,8 +2333,7 @@ static irqreturn_t stmmac_interrupt(int irq, void
>> *dev_id)
>>
>> /* To handle GMAC own interrupts */
>> if (priv->plat->has_gmac) {
>> - int status = priv->hw->mac->host_irq_status((void __iomem
>> *)
>> -
>> dev->base_addr,
>> + int status = priv->hw->mac->host_irq_status(priv->hw,
>>
>> &priv->xstats);
>> if (unlikely(status)) {
>> /* For LPI we need to save the tx status */
>> @@ -2619,7 +2617,9 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
>> /* Identify the MAC HW device */
>> if (priv->plat->has_gmac) {
>> priv->dev->priv_flags |= IFF_UNICAST_FLT;
>> - mac = dwmac1000_setup(priv->ioaddr);
>> + mac = dwmac1000_setup(priv->ioaddr,
>> + priv->plat->multicast_filter_bins,
>> + priv->plat->unicast_filter_entries);
>> } else {
>> mac = dwmac100_setup(priv->ioaddr);
>> }
>> @@ -2668,7 +2668,7 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
>> /* To use alternate (extended) or normal descriptor structures */
>> stmmac_selec_desc_mode(priv);
>>
>> - ret = priv->hw->mac->rx_ipc(priv->ioaddr);
>> + ret = priv->hw->mac->rx_ipc(priv->hw);
>> if (!ret) {
>> pr_warn(" RX IPC Checksum Offload not configured.\n");
>> priv->plat->rx_coe = STMMAC_RX_COE_NONE;
>> @@ -2888,7 +2888,7 @@ int stmmac_suspend(struct net_device *ndev)
>>
>> /* Enable Power down mode by programming the PMT regs */
>> if (device_may_wakeup(priv->device)) {
>> - priv->hw->mac->pmt(priv->ioaddr, priv->wolopts);
>> + priv->hw->mac->pmt(priv->hw, priv->wolopts);
>> priv->irq_wake = 1;
>> } else {
>> stmmac_set_mac(priv->ioaddr, false);
>> @@ -2917,7 +2917,7 @@ int stmmac_resume(struct net_device *ndev)
>> * from another devices (e.g. serial console).
>> */
>> if (device_may_wakeup(priv->device)) {
>> - priv->hw->mac->pmt(priv->ioaddr, 0);
>> + priv->hw->mac->pmt(priv->hw, 0);
>> priv->irq_wake = 0;
>> } else {
>> pinctrl_pm_select_default_state(priv->device);
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> index 5884a7d..4502cde 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
>> @@ -43,6 +43,42 @@ static const struct of_device_id stmmac_dt_ids[] = {
>> };
>> MODULE_DEVICE_TABLE(of, stmmac_dt_ids);
>>
>> +
>> +static int stmmac_validate_mcast_bins(int mcast_bins)
>> +{
>> + int x = mcast_bins;
>> + switch (x) {
>> + case 0:
>> + case HASH_TABLE_SIZE:
>> + case 128:
>> + case 256:
>> + break;
>> + default:
>> + x = HASH_TABLE_SIZE;
>> + pr_info("Hash table entries set to unexpected value %d",
>> + mcast_bins);
>> + break;
>> + }
>> + return x;
>> +}
>> +
>> +static int stmmac_validate_ucast_entries(int ucast_entries)
>> +{
>> + int x = ucast_entries;
>> + switch (x) {
>> + case 32:
>> + case 64:
>> + case 128:
>> + break;
>> + default:
>> + x = 32;
>> + pr_info("Unicast table entries set to unexpected value
>> %d\n",
>> + ucast_entries);
>> + break;
>> + }
>> + return x;
>> +}
>> +
>> #ifdef CONFIG_OF
>> static int stmmac_probe_config_dt(struct platform_device *pdev,
>> struct plat_stmmacenet_data *plat,
>> @@ -107,6 +143,13 @@ static int stmmac_probe_config_dt(struct
>> platform_device *pdev,
>> */
>> plat->maxmtu = JUMBO_LEN;
>>
>> + /* Set default value for multicast hash bins */
>> + plat->multicast_filter_bins = HASH_TABLE_SIZE;
>> +
>> + /* Set default value for unicast filter entries */
>> + plat->unicast_filter_entries = GMAC_MAX_PERFECT_ADDRESSES;
>> +
>> +
>> /*
>> * Currently only the properties needed on SPEAr600
>> * are provided. All other properties should be added
>> @@ -123,6 +166,14 @@ static int stmmac_probe_config_dt(struct
>> platform_device *pdev,
>> * are clearly MTUs
>> */
>> of_property_read_u32(np, "max-frame-size", &plat->maxmtu);
>> + of_property_read_u32(np, "snps,multicast-filter-bins",
>> + &plat->multicast_filter_bins);
>> + of_property_read_u32(np, "snps,perfect-filter-entries",
>> + &plat->unicast_filter_entries);
>> + plat->unicast_filter_entries =
>> stmmac_validate_ucast_entries(
>> + plat->unicast_filter_entries);
>> + plat->multicast_filter_bins = stmmac_validate_mcast_bins(
>> + plat->multicast_filter_bins);
>
>
>
> Can this validation be done in main?
Yes, I will make this change for the next submission, along with any
comprehending any technical information from Synopsys on the unicast
filter.
>
>
>> plat->has_gmac = 1;
>> plat->pmt = 1;
>> }
>> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
>> index 6f27d4f..cd63851 100644
>> --- a/include/linux/stmmac.h
>> +++ b/include/linux/stmmac.h
>> @@ -112,6 +112,8 @@ struct plat_stmmacenet_data {
>> int riwt_off;
>> int max_speed;
>> int maxmtu;
>> + int multicast_filter_bins;
>> + int unicast_filter_entries;
>> void (*fix_mac_speed)(void *priv, unsigned int speed);
>> void (*bus_setup)(void __iomem *ioaddr);
>> void *(*setup)(struct platform_device *pdev);
>>
>
Thanks,
ATB!
Vince
^ permalink raw reply
* Re: [PATCH 3/6] mfd: add bcm59056 pmu driver
From: Mark Brown @ 2014-02-04 17:11 UTC (permalink / raw)
To: Lee Jones
Cc: Mark Rutland, Devicetree List, Christian Daudt, Samuel Ortiz,
Pawel Moll, Wolfram Sang, Tim Kryger, Ian Campbell, Liam Girdwood,
Matt Porter, Linux Kernel Mailing List, Rob Herring,
Linux I2C List, Kumar Gala, Linux ARM Kernel List
In-Reply-To: <20140204170832.GA5196@lee--X1>
[-- Attachment #1.1: Type: text/plain, Size: 583 bytes --]
On Tue, Feb 04, 2014 at 05:08:32PM +0000, Lee Jones wrote:
> > What using of_match_ptr() should do is allow the compiler to figure out
> > that the table isn't used when DT is disabled and discard it without
> > ifdefs. Not sure if that actually works yet but that's the idea.
> Right, but I'm guessing that as there is no support for platform data
> then this device(s) is going to be DT only? If that's the case perhaps
> a 'depends OF' might be in order. If that's not the case then I'm more
> than happy to leave the of_match_ptr() in.
Hey, we'll all be using ACPI soon! :P
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V3] net/dt: Add support for overriding phy configuration from device tree
From: Grant Likely @ 2014-02-04 17:15 UTC (permalink / raw)
To: netdev; +Cc: devicetree, linux-kernel, kishon, Matthew Garrett
In-Reply-To: <1389999459-9483-1-git-send-email-matthew.garrett@nebula.com>
On Fri, 17 Jan 2014 17:57:39 -0500, Matthew Garrett <matthew.garrett@nebula.com> wrote:
> Some hardware may be broken in interesting and board-specific ways, such
> that various bits of functionality don't work. This patch provides a
> mechanism for overriding mii registers during init based on the contents of
> the device tree data, allowing board-specific fixups without having to
> pollute generic code.
>
> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
I've got no problems in principle with the feature. I think it is a good
change. The binding itself feels too verbose to me. As an alternative,
how about the following:
phy-mii-advertise = "10half", "!10full", "!100base4"
So it is a list of features. Prepending a '!' makes it disabled. And we
could add something like "nodefault" to clear the probed settings
entirely before listing the modes we want.
g.
> ---
>
> V3: Break the main function out into some helper functions and store the
> values in some structs.
>
> Documentation/devicetree/bindings/net/phy.txt | 21 +++++++
> drivers/net/phy/phy_device.c | 29 ++++++++-
> drivers/of/of_net.c | 87 +++++++++++++++++++++++++++
> include/linux/of_net.h | 12 ++++
> 4 files changed, 148 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
> index 7cd18fb..fc50f02 100644
> --- a/Documentation/devicetree/bindings/net/phy.txt
> +++ b/Documentation/devicetree/bindings/net/phy.txt
> @@ -23,6 +23,21 @@ Optional Properties:
> assume clause 22. The compatible list may also contain other
> elements.
>
> +The following properties may be added to either the phy node or the parent
> +ethernet device. If not present, the hardware defaults will be used.
> +
> +- phy-mii-advertise-10half: 1 to advertise half-duplex 10MBit, 0 to disable
> +- phy-mii-advertise-10full: 1 to advertise full-duplex 10MBit, 0 to disable
> +- phy-mii-advertise-100half: 1 to advertise half-duplex 100MBit, 0 to disable
> +- phy-mii-advertise-100full: 1 to advertise full-duplex 100MBit, 0 to disable
> +- phy-mii-advertise-100base4: 1 to advertise 100base4, 0 to disable
> +- phy-mii-advertise-1000half: 1 to advertise half-duplex 1000MBit, 0 to disable
> +- phy-mii-advertise-1000full: 1 to advertise full-duplex 1000MBit, 0 to disable
> +- phy-mii-manual-master: 1 to enable manual master/slave configuration, 0
> + to disable manual master/slave configuration
> +- phy-mii-as-master: 1 to configure phy to act as master, 0 to configure phy
> + to act as slave. Ignored if manual master/slave configuration is not enabled.
> +
> Example:
>
> ethernet-phy@0 {
> @@ -32,4 +47,10 @@ ethernet-phy@0 {
> interrupts = <35 1>;
> reg = <0>;
> device_type = "ethernet-phy";
> + // Disable advertising of full duplex 1000MBit
> + phy-mii-advertise-1000full = <0>;
> + // Force manual phy master/slave configuration
> + phy-mii-manual-master = <1>;
> + // Forcibly configure phy as slave
> + phy-mii-as-master = <0>;
> };
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index d6447b3..91793bc 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -33,6 +33,7 @@
> #include <linux/mii.h>
> #include <linux/ethtool.h>
> #include <linux/phy.h>
> +#include <linux/of_net.h>
>
> #include <asm/io.h>
> #include <asm/irq.h>
> @@ -497,6 +498,28 @@ void phy_disconnect(struct phy_device *phydev)
> }
> EXPORT_SYMBOL(phy_disconnect);
>
> +int phy_override_from_of(struct phy_device *phydev)
> +{
> + int reg, regval;
> + u16 val, mask;
> +
> + /* Check for phy register overrides from OF */
> + for (reg = 0; reg < 16; reg++) {
> + if (!of_get_mii_register(phydev, reg, &val, &mask)) {
> + if (!mask)
> + continue;
> + regval = phy_read(phydev, reg);
> + if (regval < 0)
> + continue;
> + regval &= ~mask;
> + regval |= val;
> + phy_write(phydev, reg, regval);
> + }
> + }
> +
> + return 0;
> +}
> +
> int phy_init_hw(struct phy_device *phydev)
> {
> int ret;
> @@ -508,7 +531,11 @@ int phy_init_hw(struct phy_device *phydev)
> if (ret < 0)
> return ret;
>
> - return phydev->drv->config_init(phydev);
> + ret = phydev->drv->config_init(phydev);
> + if (ret < 0)
> + return ret;
> +
> + return phy_override_from_of(phydev);
> }
>
> /**
> diff --git a/drivers/of/of_net.c b/drivers/of/of_net.c
> index 8f9be2e..75751b7 100644
> --- a/drivers/of/of_net.c
> +++ b/drivers/of/of_net.c
> @@ -93,3 +93,90 @@ const void *of_get_mac_address(struct device_node *np)
> return NULL;
> }
> EXPORT_SYMBOL(of_get_mac_address);
> +
> +struct mii_override {
> + char *prop;
> + u32 supported;
> + u16 value;
> +};
> +
> +static struct mii_override mii_advertise_override[] = {
> + { "phy-mii-advertise-10half", SUPPORTED_10baseT_Half,
> + ADVERTISE_10HALF },
> + { "phy-mii-advertise-10full", SUPPORTED_10baseT_Full,
> + ADVERTISE_10FULL },
> + { "phy-mii-advertise-100half", SUPPORTED_100baseT_Half,
> + ADVERTISE_100HALF },
> + { "phy-mii-advertise-100full", SUPPORTED_100baseT_Full,
> + ADVERTISE_100FULL },
> + { "phy-mii-advertise-100base4", 0, ADVERTISE_100BASE4 },
> + { NULL },
> +};
> +
> +static struct mii_override mii_gigabit_override[] = {
> + { "phy-mii-advertise-1000half", SUPPORTED_1000baseT_Half,
> + ADVERTISE_1000HALF },
> + { "phy-mii-advertise-1000full", SUPPORTED_1000baseT_Full,
> + ADVERTISE_1000FULL },
> + { "phy-mii-as-master", 0, CTL1000_AS_MASTER },
> + { "phy-mii-manual-master", 0, CTL1000_ENABLE_MASTER },
> + { NULL },
> +};
> +
> +static void mii_handle_override(struct mii_override *override_list,
> + struct phy_device *phydev, u16 *val, u16 *mask)
> +{
> + struct device *dev = &phydev->dev;
> + struct device_node *np = dev->of_node;
> + struct mii_override *override;
> + u32 tmp;
> +
> + if (!np && dev->parent->of_node)
> + np = dev->parent->of_node;
> +
> + if (!np)
> + return;
> +
> + for (override = &override_list[0]; override->prop != NULL; override++) {
> + if (!of_property_read_u32(np, override->prop, &tmp)) {
> + if (tmp) {
> + *val |= override->value;
> + phydev->advertising |= override->supported;
> + } else {
> + phydev->advertising &= ~(override->supported);
> + }
> +
> + *mask |= override->value;
> + }
> + }
> +
> + return;
> +}
> +
> +/**
> + * Provide phy register overrides from the device tree. Some hardware may
> + * be broken in interesting and board-specific ways, so we want a mechanism
> + * for the board data to provide overrides for default values. This should be
> + * called during phy init.
> + */
> +int of_get_mii_register(struct phy_device *phydev, int reg, u16 *val,
> + u16 *mask)
> +{
> + *val = 0;
> + *mask = 0;
> +
> + switch (reg) {
> + case MII_ADVERTISE:
> + mii_handle_override(mii_advertise_override, phydev, val, mask);
> + break;
> +
> + case MII_CTRL1000:
> + mii_handle_override(mii_gigabit_override, phydev, val, mask);
> + break;
> +
> + default:
> + return -EINVAL;
> + }
> + return 0;
> +}
> +EXPORT_SYMBOL(of_get_mii_register);
> diff --git a/include/linux/of_net.h b/include/linux/of_net.h
> index 34597c8..2e478bc 100644
> --- a/include/linux/of_net.h
> +++ b/include/linux/of_net.h
> @@ -7,10 +7,14 @@
> #ifndef __LINUX_OF_NET_H
> #define __LINUX_OF_NET_H
>
> +#include <linux/phy.h>
> +
> #ifdef CONFIG_OF_NET
> #include <linux/of.h>
> extern int of_get_phy_mode(struct device_node *np);
> extern const void *of_get_mac_address(struct device_node *np);
> +extern int of_get_mii_register(struct phy_device *np, int reg, u16 *val,
> + u16 *mask);
> #else
> static inline int of_get_phy_mode(struct device_node *np)
> {
> @@ -21,6 +25,14 @@ static inline const void *of_get_mac_address(struct device_node *np)
> {
> return NULL;
> }
> +static inline int of_get_mii_register(struct phy_device *np, int reg, u16 *val,
> + u16 *mask)
> +{
> + *val = 0;
> + *mask = 0;
> +
> + return -EINVAL;
> +}
> #endif
>
> #endif /* __LINUX_OF_NET_H */
> --
> 1.8.4.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCHv2 1/2] of: add __of_add_property() without lock operations
From: Grant Likely @ 2014-02-04 17:22 UTC (permalink / raw)
To: robh+dt; +Cc: panto, devicetree, linux-kernel, Xiubo Li
In-Reply-To: <1390370260-11273-1-git-send-email-Li.Xiubo@freescale.com>
On Wed, 22 Jan 2014 13:57:39 +0800, Xiubo Li <Li.Xiubo@freescale.com> wrote:
> There two places will use the same code for adding one new property to
> the DT node. Adding __of_add_property() and prepare for fixing
> of_update_property()'s bug.
>
> Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
Applied, thanks.
g.
> ---
> drivers/of/base.c | 38 ++++++++++++++++++++++++--------------
> 1 file changed, 24 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index f807d0e..b86b77a 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -1469,11 +1469,31 @@ static int of_property_notify(int action, struct device_node *np,
> #endif
>
> /**
> + * __of_add_property - Add a property to a node without lock operations
> + */
> +static int __of_add_property(struct device_node *np, struct property *prop)
> +{
> + struct property **next;
> +
> + prop->next = NULL;
> + next = &np->properties;
> + while (*next) {
> + if (strcmp(prop->name, (*next)->name) == 0)
> + /* duplicate ! don't insert it */
> + return -EEXIST;
> +
> + next = &(*next)->next;
> + }
> + *next = prop;
> +
> + return 0;
> +}
> +
> +/**
> * of_add_property - Add a property to a node
> */
> int of_add_property(struct device_node *np, struct property *prop)
> {
> - struct property **next;
> unsigned long flags;
> int rc;
>
> @@ -1481,27 +1501,17 @@ int of_add_property(struct device_node *np, struct property *prop)
> if (rc)
> return rc;
>
> - prop->next = NULL;
> raw_spin_lock_irqsave(&devtree_lock, flags);
> - next = &np->properties;
> - while (*next) {
> - if (strcmp(prop->name, (*next)->name) == 0) {
> - /* duplicate ! don't insert it */
> - raw_spin_unlock_irqrestore(&devtree_lock, flags);
> - return -1;
> - }
> - next = &(*next)->next;
> - }
> - *next = prop;
> + rc = __of_add_property(np, prop);
> raw_spin_unlock_irqrestore(&devtree_lock, flags);
>
> #ifdef CONFIG_PROC_DEVICETREE
> /* try to add to proc as well if it was initialized */
> - if (np->pde)
> + if (!rc && np->pde)
> proc_device_tree_add_prop(np->pde, prop);
> #endif /* CONFIG_PROC_DEVICETREE */
>
> - return 0;
> + return rc;
> }
>
> /**
> --
> 1.8.4
>
>
^ permalink raw reply
* Re: [PATCH 2/6] regulator: add bcm59056 pmu DT binding
From: Mark Brown @ 2014-02-04 17:23 UTC (permalink / raw)
To: Matt Porter
Cc: Wolfram Sang, Tim Kryger, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Liam Girdwood,
Christian Daudt, Devicetree List, Linux I2C List,
Linux ARM Kernel List, Linux Kernel Mailing List
In-Reply-To: <1391516352-32359-3-git-send-email-mporter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 595 bytes --]
On Tue, Feb 04, 2014 at 07:19:08AM -0500, Matt Porter wrote:
> Add a DT binding for the BCM59056 PMU. The binding inherits from
> the generic regulator bindings.
Is this really only a regulator - does the chip have no other functions?
> +- regulators: This is the list of child nodes that specify the regulator
> + initialization data for defined regulators. Generic regulator bindings
> + are described in regulator/regulator.txt.
The regulators property should always be optional, the driver should be
able to start up and read back the hardware state without any further
configuration.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCHv2 2/2] of: fix of_update_property()
From: Grant Likely @ 2014-02-04 17:24 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Xiubo Li
In-Reply-To: <1390370260-11273-2-git-send-email-Li.Xiubo-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
On Wed, 22 Jan 2014 13:57:40 +0800, Xiubo Li <Li.Xiubo-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> The of_update_property() is intented to update a property in a node
> and if the property does not exist, will add it.
>
> The second search of the property is possibly won't be found, that
> maybe removed by other thread just before the second search begain.
>
> Using the __of_find_property() and __of_add_property() instead and
> move them into lock operations.
>
> Signed-off-by: Xiubo Li <Li.Xiubo-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> Cc: Pantelis Antoniou <panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org>
Applied, thanks
g.
> ---
> drivers/of/base.c | 36 ++++++++++++++----------------------
> 1 file changed, 14 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index b86b77a..458072d 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -1573,7 +1573,7 @@ int of_update_property(struct device_node *np, struct property *newprop)
> {
> struct property **next, *oldprop;
> unsigned long flags;
> - int rc, found = 0;
> + int rc = 0;
>
> rc = of_property_notify(OF_RECONFIG_UPDATE_PROPERTY, np, newprop);
> if (rc)
> @@ -1582,36 +1582,28 @@ int of_update_property(struct device_node *np, struct property *newprop)
> if (!newprop->name)
> return -EINVAL;
>
> - oldprop = of_find_property(np, newprop->name, NULL);
> - if (!oldprop)
> - return of_add_property(np, newprop);
> -
> raw_spin_lock_irqsave(&devtree_lock, flags);
> - next = &np->properties;
> - while (*next) {
> - if (*next == oldprop) {
> - /* found the node */
> - newprop->next = oldprop->next;
> - *next = newprop;
> - oldprop->next = np->deadprops;
> - np->deadprops = oldprop;
> - found = 1;
> - break;
> - }
> - next = &(*next)->next;
> + oldprop = __of_find_property(np, newprop->name, NULL);
> + if (!oldprop) {
> + /* add the node */
> + rc = __of_add_property(np, newprop);
> + } else {
> + /* replace the node */
> + next = &oldprop;
> + newprop->next = oldprop->next;
> + *next = newprop;
> + oldprop->next = np->deadprops;
> + np->deadprops = oldprop;
> }
> raw_spin_unlock_irqrestore(&devtree_lock, flags);
>
> - if (!found)
> - return -ENODEV;
> -
> #ifdef CONFIG_PROC_DEVICETREE
> /* try to add to proc as well if it was initialized */
> - if (np->pde)
> + if (!rc && np->pde)
> proc_device_tree_update_prop(np->pde, newprop, oldprop);
> #endif /* CONFIG_PROC_DEVICETREE */
>
> - return 0;
> + return rc;
> }
>
> #if defined(CONFIG_OF_DYNAMIC)
> --
> 1.8.4
>
>
--
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
* [PATCH 1/2] devicetree: Add Xilinx XADC binding documentation
From: Lars-Peter Clausen @ 2014-02-04 17:24 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Michal Simek, linux-iio-u79uwXL29TY76Z2rM5mHXA,
Lars-Peter Clausen, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree-u79uwXL29TY76Z2rM5mHXA
The Xilinx XADC is a ADC that can be found in the series 7 FPGAs from Xilinx.
The XADC has a DRP interface for communication. Currently two different
frontends for the DRP interface exist. One that is only available on the ZYNQ
family as a hardmacro in the SoC portion of the ZYNQ. The other one is available
on all series 7 platforms and is a softmacro with a AXI interface. This binding
document describes the bindings for both of them since the bindings are very
similar.
Each of them needs:
* A address range where the registers are mapped
* An interrupt number for the device interrupt
* A clock. For the the ZYNQ hardmacro interface this is the modules PCAP
clock, for the AXI softmacro it is the AXI bus interface clock.
Additionally the bindings specify whether an external multiplexer is used and in
which mode it is used. The devicetree bindings also describe which external
channels are connected and in which configuration.
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
---
.../devicetree/bindings/iio/adc/xilinx-xadc.txt | 119 +++++++++++++++++++++
1 file changed, 119 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt b/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt
new file mode 100644
index 0000000..40d97c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt
@@ -0,0 +1,119 @@
+Xilinx XADC device driver
+
+The Xilinx XADC is a ADC that can be found in the series 7 FPGAs from Xilinx.
+The XADC has a DRP interface for communication. Currently two different
+frontends for the DRP interface exist. One that is only available on the ZYNQ
+family as a hardmacro in the SoC portion of the ZYNQ. The other one is
+available on all series 7 platforms and is a softmacro with a AXI interface.
+
+This binding document describes the bindings for both of them since the
+bindings are very similar. The Xilinx XADC is a ADC that can be found in the
+series 7 FPGAs from Xilinx. The XADC has a DRP interface for communication.
+Currently two different frontends for the DRP interface exist. One that is only
+available on the ZYNQ family as a hardmacro in the SoC portion of the ZYNQ. The
+other one is available on all series 7 platforms and is a softmacro with a AXI
+interface. This binding document describes the bindings for both of them since
+the bindings are very similar.
+
+Required properties:
+ - compatible: Should be one of
+ * "xlnx,zynq-xadc-1.00.a": When using the ZYNQ device
+ configuration interface to interface to the XADC hardmacro.
+ * "xlnx,axi-xadc-1.00.a": When using the axi-xadc pcore to
+ interface to the XADC hardmacro.
+ - reg: Address and length of the register set for the device
+ - interrupts: Interrupt for the XADC control interface.
+ - clocks: When using the ZYNQ this must be the ZYNQ PCAP clock,
+ when using the AXI-XADC pcore this must be the clock that provides the
+ clock to the AXI bus interface of the core.
+
+Optional properties:
+ - interrupt-parent: phandle to the parent interrupt controller
+ - xlnx,external-mux:
+ * "none": No external multiplexer is used, this is the default
+ if the property is omitted.
+ * "single": External multiplexer mode is used with one
+ multiplexer.
+ * "dual": External multiplexer mode is used with two
+ multiplexers for simultaneous sampling.
+ - xlnx,external-mux-channel: Configures which pair of pins is used to
+ sample data in external mux mode.
+ Valid values for single external multiplexer mode are:
+ 0: VP/VN
+ 1: VAUXP[0]/VAUXN[0]
+ 2: VAUXP[1]/VAUXN[1]
+ ...
+ 16: VAUXP[15]/VAUXN[15]
+ Valid values for dual external multiplexer mode are:
+ 1: VAUXP[0]/VAUXN[0] - VAUXP[8]/VAUXN[8]
+ 2: VAUXP[1]/VAUXN[1] - VAUXP[9]/VAUXN[9]
+ ...
+ 8: VAUXP[7]/VAUXN[7] - VAUXP[15]/VAUXN[15]
+
+ This property needs to be present if the device is configured for
+ external multiplexer mode (either single or dual). If the device is
+ not using external multiplexer mode the property is ignored.
+ - xnlx,channels: List of external channels that are connected to the ADC
+ Required properties:
+ * #address-cells: Should be 1.
+ * #size-cells: Should be 0.
+
+ The child nodes of this node represent the external channels which are
+ connected to the ADC. If the property is no present no external
+ channels will be assumed to be connected.
+
+ Each child node represents one channel and has the following
+ properties:
+ Required properties:
+ * reg: Pair of pins the the channel is connected to.
+ 0: VP/VN
+ 1: VAUXP[0]/VAUXN[0]
+ 2: VAUXP[1]/VAUXN[1]
+ ...
+ 16: VAUXP[15]/VAUXN[15]
+ Note each channel number should only be used at most
+ once.
+ Optional properties:
+ * xlnx,bipolar: If set the channel is used in bipolar
+ mode.
+
+
+Examples:
+ xadc@f8007100 {
+ compatible = "xlnx,zynq-xadc-1.00.a";
+ reg = <0xf8007100 0x20>;
+ interrupts = <0 7 4>;
+ interrupt-parent = <&gic>;
+ clocks = <&pcap_clk>;
+
+ xlnx,channels {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel@0 {
+ reg = <0>;
+ };
+ channel@1 {
+ reg = <1>;
+ };
+ channel@8 {
+ reg = <8>;
+ };
+ };
+ };
+
+ xadc@43200000 {
+ compatible = "xlnx,axi-xadc-1.00.a";
+ reg = <0x43200000 0x1000>;
+ interrupts = <0 53 4>;
+ interrupt-parent = <&gic>;
+ clocks = <&fpga1_clk>;
+
+ xlnx,channels {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ channel@0 {
+ reg = <0>;
+ xlnx,bipolar;
+ };
+ };
+ };
--
1.8.0
^ permalink raw reply related
* Re: [PATCH net-next 1/2] dts: Add bindings for multicast hash bins and perfect filter entries
From: Rob Herring @ 2014-02-04 17:25 UTC (permalink / raw)
To: Vince Bridgers
Cc: devicetree@vger.kernel.org, netdev, Giuseppe CAVALLARO,
Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Dinh Nguyen, Rayagond Kokatanur
In-Reply-To: <1391199356-27226-2-git-send-email-vbridgers2013@gmail.com>
On Fri, Jan 31, 2014 at 2:15 PM, Vince Bridgers <vbridgers2013@gmail.com> wrote:
> This change adds bindings for the number of multicast hash bins and perfect
> filter entries supported by the Synopsys EMAC. The Synopsys EMAC core is
> configurable at device creation time, and can be configured for a different
> number of multicast hash bins and a different number of perfect filter entries.
> The device does not provide a way to query these parameters, therefore
> parameters are required. The Altera Cyclone V SOC has support for 256
> multicast hash bins and 128 perfect filter entries, and is different than
> what's currently provided in the stmmac driver.
>
> Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/net/stmmac.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
> index 9d92d42..dbf7498 100644
> --- a/Documentation/devicetree/bindings/net/stmmac.txt
> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
> @@ -34,6 +34,10 @@ Optional properties:
> reset phandle is given
> - max-frame-size: Maximum Transfer Unit (IEEE defined MTU), rather
> than the maximum frame size.
> +- snps,multicast-filter-bins: Number of multicast filter hash bins
> + supported by this device instance
> +- snps,perfect-filter-entries: Number of perfect filter entries supported
> + by this device instance
>
> Examples:
>
> @@ -46,4 +50,6 @@ Examples:
> mac-address = [000000000000]; /* Filled in by U-Boot */
> max-frame-size = <3800>;
> phy-mode = "gmii";
> + snps,multicast-filter-bins = <256>;
> + snps,perfect-filter-entries = <128>;
> };
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [PATCH] DT: net: document Ethernet bindings in one place
From: Grant Likely @ 2014-02-04 17:26 UTC (permalink / raw)
To: Sergei Shtylyov, Florian Fainelli, Rob Herring
Cc: netdev, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, devicetree@vger.kernel.org, Rob Landley,
linux-doc@vger.kernel.org
In-Reply-To: <52E988FA.8040807@cogentembedded.com>
On Thu, 30 Jan 2014 02:04:26 +0300, Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> wrote:
> Hello.
>
> On 01/22/2014 12:19 AM, Sergei Shtylyov wrote:
>
> >>>>> I'm afraid that's too late, it has spread very far, so that
> >>>>> of_get_phy_mode() handles that property, not "phy-connection-type".
>
> >>>> Uggg, I guess this is a case of a defacto standard then if the kernel
> >>>> doesn't even support it.
>
> >>> Maybe I forgot to CC you on patch sent to Grant only, I sent a patch a
> >>> while ago for of_get_phy_mode() to look for both "phy-mode" and
> >>> "phy-connection-type" since the former has been a Linux invention, but
> >>> the latter is ePAPR specified.
>
> >> Here is a link to the actual patch in question, not sure which tree
> >> Grant applied it to though:
>
> >> http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00048.html
>
> > It's not the patch mail, it's Grant's "applied" reply, patch is mangled in
> > this reply, and I couldn't follow the thread. Here's the actual patch mail:
>
> > http://marc.info/?l=devicetree&m=138449662807254
>
> Florian, I didn't find this patch in Grant's official tree, so maybe you
> should ask him where is the patch already?
Sorry, I accidentally dropped it. It will be in the next merge window.
g.
^ permalink raw reply
* RE: [PATCH] of: fix of_update_property()
From: Grant Likely @ 2014-02-04 17:26 UTC (permalink / raw)
To: Li.Xiubo-KZfg59tc24xl57MIdRCFDg@public.gmane.org, Rob Herring
Cc: Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Pantelis Antoniou
In-Reply-To: <b61be84c13ed4056a62743e16beb70f2-+7O3WWA3DPshjIn37xzcLOO6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
On Mon, 20 Jan 2014 05:50:17 +0000, "Li.Xiubo-KZfg59tc24xl57MIdRCFDg@public.gmane.org" <Li.Xiubo-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > Subject: Re: [PATCH] of: fix of_update_property()
> >
> > On Thu, Jan 16, 2014 at 10:46 PM, Xiubo Li <Li.Xiubo-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > The of_update_property() is intent to update a property in a node
> >
> > s/intent/indended/
> >
> > > and if the property does not exist, will add it to the node.
> > >
> > > The second search of the property is possibly won't be found, that
> > > maybe removed by other thread just before the second search begain,
> > > if so just retry it.
> >
> > How did you find this problem? Actual use or some artificial stress test?
> >
>
> Some artificial stress test at home.
Can you reproduce those tests? It would be nice to have the selftests in
the kernel so that we can regression test for problems like this.
g.
--
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 4/6] regulator: add bcm59056 regulator driver
From: Mark Brown @ 2014-02-04 17:28 UTC (permalink / raw)
To: Matt Porter
Cc: Wolfram Sang, Tim Kryger, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Samuel Ortiz, Lee Jones, Liam Girdwood,
Christian Daudt, Devicetree List, Linux I2C List,
Linux ARM Kernel List, Linux Kernel Mailing List
In-Reply-To: <1391516352-32359-5-git-send-email-mporter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]
On Tue, Feb 04, 2014 at 07:19:10AM -0500, Matt Porter wrote:
> +static unsigned int bcm59056_get_mode(struct regulator_dev *dev)
> +{
> + return REGULATOR_MODE_NORMAL;
> +}
> +
> +static int bcm59056_set_mode(struct regulator_dev *dev, unsigned int mode)
> +{
> + if (mode == REGULATOR_MODE_NORMAL)
> + return 0;
> + else
> + return -EINVAL;
> +}
These do nothing, don't implement them.
> + if (bcm59056->dev->of_node)
> + pmu_data = bcm59056_parse_dt_reg_data(pdev,
> + &bcm59056_reg_matches);
It'd seem a bit neater to put the OF check into the parse function but
meh.
> + if (!pmu_data) {
> + dev_err(&pdev->dev, "Platform data not found\n");
> + return -EINVAL;
> + }
Like I said when reviewing the binding this should not cause the driver
to fail to load.
> + /*
> + * Regulator API handles empty constraints but not NULL
> + * constraints
> + */
> + if (!reg_data)
> + continue;
It should do... if not then make it so since that'd mean most drivers
are buggy.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4] of: add functions to count number of elements in a property
From: Grant Likely @ 2014-02-04 17:30 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree@vger.kernel.org, Pawel Moll,
Stephen Warren, Ian Campbell, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAL_JsqJord1OOjwcKk1jqF5o+XO3uw+Lc4ATtQacgwZWAoQq1g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 706 bytes --]
On Sat, 18 Jan 2014 09:07:30 -0600, Rob Herring <robherring2@gmail.com> wrote:
> On Sat, Jan 18, 2014 at 6:02 AM, Heiko Stübner <heiko@sntech.de> wrote:
> > The need to know the number of array elements in a property is
> > a common pattern. To prevent duplication of open-coded implementations
> > add a helper static function that also centralises strict sanity
> > checking and DTB format details, as well as a set of wrapper functions
> > for u8, u16, u32 and u64.
> >
> > Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > ---
>
> Looks good. Do you plan to convert some users to use this?
I'll take that as an acked-by. Merged, thanks.
g.
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 08/11] of: Increase MAX_PHANDLE_ARGS
From: Grant Likely @ 2014-02-04 17:33 UTC (permalink / raw)
To: Suravee Suthikulanit, Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Will Deacon,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Rob Herring, Andreas Herrmann,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <52E93360.1000904-5C7GfCeVMHo@public.gmane.org>
On Wed, 29 Jan 2014 10:59:12 -0600, Suravee Suthikulanit <suravee.suthikulpanit-5C7GfCeVMHo@public.gmane.org> wrote:
> On 1/29/2014 10:57 AM, Rob Herring wrote:
> >>> diff --git a/include/linux/of.h b/include/linux/of.h
> >>> >>index 276c546..24e1b28 100644
> >>> >>--- a/include/linux/of.h
> >>> >>+++ b/include/linux/of.h
> >>> >>@@ -67,7 +67,7 @@ struct device_node {
> >>> >> #endif
> >>> >> };
> >>> >>
> >>> >>-#define MAX_PHANDLE_ARGS 8
> >>> >>+#define MAX_PHANDLE_ARGS 16
> >> >
> >> >
> >> >Since the MMU-500 specify "Number of SMRs" upto 128 registers, shouldn't
> >> >this be changed to be able to support 128 StreamIDs as well? Although I am
> >> >not sure if this would be too big to have on the stack per Rob's comment in
> >> >the previous patch set.
> > Do you actually need 128 now? If not, then we can deal with that when
> > we get there. There are lots of things in spec's that are not actually
> > implemented or supported.
>
> Actually, we are using 32 on the AMD system. So, do you think we can set
> this to 32 instead?
The helper really wasn't designed for large number of arguments to a
phandle. If the phandle args are really that large, then it may be
better to have a parser that allocates the space needed and/or puts the
data directly into the destination data structure.
g.
^ permalink raw reply
* Re: [PATCH v2 08/11] of: Increase MAX_PHANDLE_ARGS
From: Grant Likely @ 2014-02-04 17:36 UTC (permalink / raw)
To: Andreas Herrmann, Will Deacon
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Rob Herring,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20140117110830.GW3471@alberich>
On Fri, 17 Jan 2014 12:08:30 +0100, Andreas Herrmann <andreas.herrmann-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org> wrote:
>
> arm-smmu driver uses of_parse_phandle_with_args when parsing DT
> information to determine stream IDs for a master device.
> Thus the number of stream IDs per master device is bound by
> MAX_PHANDLE_ARGS.
>
> To support Calxeda ECX-2000 hardware arm-smmu driver requires a
> slightly higher value for MAX_PHANDLE_ARGS as this hardware has 10
> stream IDs for one master device.
>
> Increasing it to 16 seems a reasonable choice.
>
> Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Andreas Herrmann <herrmann.der.user-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Andreas Herrmann <andreas.herrmann-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
I've merged this one, but I'm not excited about making it any larger
because this structure lives on the stack most of the time.
g.
^ permalink raw reply
* Re: Extending OPP bindings
From: Nishanth Menon @ 2014-02-04 18:01 UTC (permalink / raw)
To: Lorenzo Pieralisi, Rob Herring
Cc: Sudeep Holla, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
Mark Rutland, Charles Garcia-Tobin, Rob Herring,
grant.likely@linaro.org, Morten Rasmussen, Shawn Guo,
mturquette@linaro.org, Mark Brown, Eduardo Valentin
In-Reply-To: <20140131180929.GH2616@e102568-lin.cambridge.arm.com>
On 01/31/2014 12:09 PM, Lorenzo Pieralisi wrote:
> Hi Rob,
>
> thanks for having a look.
>
> On Fri, Jan 31, 2014 at 05:17:51PM +0000, Rob Herring wrote:
>> On Fri, Jan 31, 2014 at 6:46 AM, Lorenzo Pieralisi
>> <lorenzo.pieralisi@arm.com> wrote:
>>> Hi Nishanth,
>>>
>>> On Fri, Jan 31, 2014 at 12:43:54AM +0000, Nishanth Menon wrote:
>>>> Hi Sudeep,
>>>>
>>>> On 01/30/2014 07:43 AM, Sudeep Holla wrote:
>>>>
>>>>>
>>>>> I am looking into a couple shortcomings in the current OPP bindings and
>>>>> how to address them. Feel free to add to the list if you think of any more
>>>>> issues that needs to be addressed or if and how any problem mentioned below
>>>>> can be handled with the existing bindings.
>>>>>
>>>>> 1. indexing: currently there are no indices in the operating-points.
>>>> indexing is based on frequency which is why the accessors use
>>>> frequency to pull out the OPP data.
>>>>
>>>> indexing is a horrible idea - on platforms where OPP may be disabled
>>>> or enabled for various reasons(see arch/arm/mach-imx/mach-imx6q.c,
>>>> arch/arm/mach-omap2/board-omap3beagle.c etc) - the indexing you see in
>>>> dts is just a myth that may not exist once the nodes are loaded and
>>>> operated upon depending on SoC variations (example efuse describing
>>>> which OPPs can be used and which not).
>>>
>>> I do not understand why. As long as a mapping from DT to data structures
>>> in the kernel is done at boot, I can see how by indexing device nodes
>>> can refer to specific OPPs. If they are disabled, amen, as long as we
>>> can point at specific operating points that should be ok.
>>>
>>> Indexing does not mean that the index in the DT is the same as the one
>>> allocated by the OS. Indexing is there to point at specific OPPs from
>>> different DT nodes, a good example are clock bindings and that's exactly
>>> how they work.
>>
>> That is not a good comparison. With clocks, you are describing which
>> physical signal coming out of a hardware block much like interrupts.
>> Granted the h/w is not typically documented that way for clocks
>> although the numbering could correspond to register bit locations as
>> interrupt numbers do. With OPP indexes, they are a totally made up
>> software construct.
>
> Well ok, it might be, what I know is that current OPPs do not allow
> other nodes to reference their properties properly, I am not sure that adding
> an index make things worse, actually they are already broken as they are.
Let me look at this in two parts:
A: In kernel data representation:
If I were to use analogy of OPP library to database, A data base needs
a key to pick out data stored inside it -> the key in opp definition
as it stands right now is frequency. you can pick up any of the data
based on that key. proposal for using index into that table adds no
real value here.
Now, we can represent OPP data in many different forms. consider two
other properties per OPP (propx and propy)
data set #0:
+------------+------------+---------+-------------+
| freq | voltage | propx | propy |
+-------------------------------------------------+
| Fa | Va | PXa | PYa |
| Fb | Vb | PXb | PYb |
| Fc | Vc | PXc | PYc |
| Fd | Vd | PXd | PYd |
+------------+------------+---------+-------------+
Can then be represented as:
in opp library, considering it to be the least common denominator:
(data set #1)
+------------+------------+
| freq | voltage |
+--------------------------
| Fa | Va |
| Fb | Vb |
| Fc | Vc |
| Fd | Vd |
+------------+------------+
where ever propx makes sense. (data set #2)
+------------+---------+
| freq | propx |
+-----------------------
| Fa | PXa |
| Fb | PXb |
| Fc | PXc |
| Fd | PXd |
+------------+---------+
where ever propy makes sense (data set #3)
+------------+-------------+
| freq | propy |
+--------------------------+
| Fa | PYa |
| Fb | PYb |
| Fc | PYc |
| Fd | PYd |
+------------+-------------+
If my memory serves me right, in database terminology, this'd be first
normal form.
This also allows for data set #2 and #3 to modify or add a data set #4
with a propz at a later point in time without impacting set #1-3.
propx,y,z can be anything - efuse bits, cpuidle c state definition, etc..
As long as the key to the data sets are all the same (frequency),
information in data set #0 is maintained. It would be in our common
long term interest to maintain the split.
>> Perhaps OPPs should be nodes so new fields can be added easily and
>> then you have a phandle for each OPP.
>
> Yeah, but the end result is the same, it has more to do with how to
> express dependencies with DT than the question on whether to use a phandle
> or an index. If we have to add phandles so be it, it is still just a way
> to reference properties for me.
B) Device tree representation of an OPP:
Here we have a ton of flexibility- I love the idea of representing
each OPP as a phandle - However, a phandle has been traditionally
meant to represent a device, I might be wrong, but i am not sure if we
have a precedence where phandle represents a property.
Having each OPP as a phandle does provide a lots of representation,
extensibility and reuse opportunity. but the same phandle will have to
be parsed by different drivers to pull out relevant data.
However when Sudeep introduced phandle approach, we did debate it's
representation and appropriate topology. if we can consider OPP as
it's own phandle and operating-points a list of OPP phandles, the pain
that we face in various driver usage can be simplified.
--
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH v3 3/5] ASoC: tda998x: add DT documentation of the tda998x CODEC
From: Mark Brown @ 2014-02-04 18:12 UTC (permalink / raw)
To: Jean-Francois Moine
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA, Dave Airlie,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Clark,
Russell King - ARM Linux
In-Reply-To: <8e4231b7a55802f58a14dd07ac5cd8b0babb1dce.1391274628.git.moinejf-GANU6spQydw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 402 bytes --]
On Sat, Feb 01, 2014 at 05:48:49PM +0100, Jean-Francois Moine wrote:
> + - compatible: must be "nxp,tda998x-codec".
It's not clear to me why there's a separate compatible here - as far as
I can see this can only appear as part of one of these devices and
there's no addressing or other information that'd account for chip
variation so I'd not expect to need to bind this independently of the
parent.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: Add architecture support for PCI
From: Jason Gunthorpe @ 2014-02-04 18:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: devicetree@vger.kernel.org, linaro-kernel@lists.linaro.org,
linux-pci, Liviu Dudau, LKML, Catalin Marinas, Bjorn Helgaas,
LAKML
In-Reply-To: <13031998.NR888KZWhk@wuerfel>
On Tue, Feb 04, 2014 at 10:44:52AM +0100, Arnd Bergmann wrote:
> Now I want to integrate the EHCI into my SoC and not waste one
> of my precious PCIe root ports, so I have to create another PCI
> domain with its own ECAM compliant config space to put it into.
> Fortunately SBSA lets me add an arbitrary number of PCI domains,
> as long as they are all strictly compliant. To software it will
Just to touch on this for others who might be reading..
IMHO any simple SOC that requires multiple domains is *broken*. A
single domain covers all reasonable needs until you get up to
mega-scale NUMA systems, encouraging people to design with multiple
domains only complicates the kernel :(
SOC internal peripherals should all show up in the bus 0 config space
of the only domain and SOC PCI-E physical ports should show up on bus
0 as PCI-PCI bridges. This is all covered in the PCI-E specs regarding
the root complex.
Generally I would expect the internal peripherals to still be
internally connected with AXI, but also connected through the ECAM
space for configuration, control, power management and address
assignment.
> 2. all address windows are set up by the boot loader, we only
> need to know the location (IMHO this should be the
> preferred way to do things regardless of SBSA).
Linux does a full address map re-assignment on boot, IIRC. You need
more magics to inhibit that if your BAR's and bridge windows don't
work.
Hot plug is a whole other thing..
> it's possible that the designware based ones get point 4 right.
The designware one's also appear to be re-purposed end point cores, so
their config handling is somewhat bonkers. Tegra got theirs sort of
close because they re-used knowledge/IP from their x86 south bridges -
but even then they didn't really implement ECAM properly for an ARM
environment.
Since config space is where everyone to date has fallen down, I think
the SBSA would have been wise to list dword by dword what a typical
ECAM config space should look like.
Jason
^ permalink raw reply
* Re: Extending OPP bindings
From: Mark Brown @ 2014-02-04 18:22 UTC (permalink / raw)
To: Nishanth Menon
Cc: Lorenzo Pieralisi, Rob Herring, Mark Rutland,
devicetree@vger.kernel.org, mturquette@linaro.org,
linux-pm@vger.kernel.org, Eduardo Valentin, Rob Herring,
Sudeep Holla, grant.likely@linaro.org, Shawn Guo,
Morten Rasmussen, linux-arm-kernel@lists.infradead.org,
Charles Garcia-Tobin
In-Reply-To: <52F12AE7.904@ti.com>
[-- Attachment #1: Type: text/plain, Size: 580 bytes --]
On Tue, Feb 04, 2014 at 12:01:11PM -0600, Nishanth Menon wrote:
> As long as the key to the data sets are all the same (frequency),
> information in data set #0 is maintained. It would be in our common
> long term interest to maintain the split.
You're assuming that the frequency is a unique key here. That may not
be the case, for example two OPPs might have the same CPU clock
(assuming that's the frequency you're referring to) but different bus
clocking and of course the CPUs or CPU clusters might be individually
scalable (this is common in big.LITTLE designs I think).
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: Add architecture support for PCI
From: Arnd Bergmann @ 2014-02-04 18:34 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: devicetree@vger.kernel.org, linaro-kernel@lists.linaro.org,
Catalin Marinas, Liviu Dudau, LKML, linux-pci, Bjorn Helgaas,
LAKML
In-Reply-To: <20140204181514.GA25695@obsidianresearch.com>
On Tuesday 04 February 2014 11:15:14 Jason Gunthorpe wrote:
> On Tue, Feb 04, 2014 at 10:44:52AM +0100, Arnd Bergmann wrote:
>
> > Now I want to integrate the EHCI into my SoC and not waste one
> > of my precious PCIe root ports, so I have to create another PCI
> > domain with its own ECAM compliant config space to put it into.
> > Fortunately SBSA lets me add an arbitrary number of PCI domains,
> > as long as they are all strictly compliant. To software it will
>
> Just to touch on this for others who might be reading..
>
> IMHO any simple SOC that requires multiple domains is *broken*. A
> single domain covers all reasonable needs until you get up to
> mega-scale NUMA systems, encouraging people to design with multiple
> domains only complicates the kernel :(
Well, the way I see it, we already have support for arbitrary
PCI domains in the kernel, and that works fine, so we can just
as well use it. That way we don't have to partition the available
256 buses among the host bridges, and anything that needs a separate
PCI config space can live in its own world. Quite often when you
have multiple PCI hosts, they actually have different ways to
get at the config space and don't even share the same driver.
On x86, any kind of HT/PCI/PCIe/PCI-x bridge is stuffed into a
single domain so they can support OSs that only know the
traditional config space access methods, but I don't see
any real advantage to that for other architectures.
> SOC internal peripherals should all show up in the bus 0 config space
> of the only domain and SOC PCI-E physical ports should show up on bus
> 0 as PCI-PCI bridges. This is all covered in the PCI-E specs regarding
> the root complex.
>
> Generally I would expect the internal peripherals to still be
> internally connected with AXI, but also connected through the ECAM
> space for configuration, control, power management and address
> assignment.
That would of course be very nice from a software perspective,
but I think that is much less likely for any practical
implementation.
> > 2. all address windows are set up by the boot loader, we only
> > need to know the location (IMHO this should be the
> > preferred way to do things regardless of SBSA).
>
> Linux does a full address map re-assignment on boot, IIRC. You need
> more magics to inhibit that if your BAR's and bridge windows don't
> work.
>
> Hot plug is a whole other thing..
I meant the I/O and memory space windows of the host bridge here,
which typically don't get reassigned (except on mvebu). For the
device resources, there is a per-host PCI_REASSIGN_ALL_RSRC
flag and pcibios_assign_all_busses() function that we typically
set on embedded systems where we don't trust the boot loader
to set this up correctly, or at all.
On server systems, I would expect to have the firmware assign
all resources and the kernel to leave them alone. On sparc
and powerpc servers, there is even a third method, which
is to trust firmware to put the correct resources for each
device into DT, overriding what is written in the BAR.
> > it's possible that the designware based ones get point 4 right.
>
> The designware one's also appear to be re-purposed end point cores, so
> their config handling is somewhat bonkers. Tegra got theirs sort of
> close because they re-used knowledge/IP from their x86 south bridges -
> but even then they didn't really implement ECAM properly for an ARM
> environment.
>
> Since config space is where everyone to date has fallen down, I think
> the SBSA would have been wise to list dword by dword what a typical
> ECAM config space should look like.
I absolutely agree.
Arnd
^ permalink raw reply
* Re: [PATCH] DT: net: document Ethernet bindings in one place
From: Sergei Shtylyov @ 2014-02-04 18:40 UTC (permalink / raw)
To: Grant Likely, Florian Fainelli, Rob Herring
Cc: netdev, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, devicetree@vger.kernel.org, Rob Landley,
linux-doc@vger.kernel.org
In-Reply-To: <20140204172602.01420C4050F@trevor.secretlab.ca>
Hello.
On 02/04/2014 08:26 PM, Grant Likely wrote:
>>>>>>> I'm afraid that's too late, it has spread very far, so that
>>>>>>> of_get_phy_mode() handles that property, not "phy-connection-type".
>>>>>> Uggg, I guess this is a case of a defacto standard then if the kernel
>>>>>> doesn't even support it.
>>>>> Maybe I forgot to CC you on patch sent to Grant only, I sent a patch a
>>>>> while ago for of_get_phy_mode() to look for both "phy-mode" and
>>>>> "phy-connection-type" since the former has been a Linux invention, but
>>>>> the latter is ePAPR specified.
>>>> Here is a link to the actual patch in question, not sure which tree
>>>> Grant applied it to though:
>>>> http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00048.html
>>> It's not the patch mail, it's Grant's "applied" reply, patch is mangled in
>>> this reply, and I couldn't follow the thread. Here's the actual patch mail:
>>> http://marc.info/?l=devicetree&m=138449662807254
>> Florian, I didn't find this patch in Grant's official tree, so maybe you
>> should ask him where is the patch already?
> Sorry, I accidentally dropped it. It will be in the next merge window.
Already saw it, thanks. Would that it was in 3.14 instead of course, so
that I could use "phy-connection-type" in my binding...
> g.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH v4] of: add functions to count number of elements in a property
From: Heiko Stübner @ 2014-02-04 18:48 UTC (permalink / raw)
To: Grant Likely, arm-DgEjT+Ai2ygdnm+yROfE0A
Cc: Rob Herring, Mark Rutland, Pawel Moll,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Stephen Warren, Ian Campbell
In-Reply-To: <20140204173034.2D899C4050F-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
Hi Grant,
On Tuesday, 4. February 2014 17:30:34 Grant Likely wrote:
> On Sat, 18 Jan 2014 09:07:30 -0600, Rob Herring <robherring2-Re5JQEeQqe8@public.gmane.orgm>
wrote:
> > On Sat, Jan 18, 2014 at 6:02 AM, Heiko Stübner <heiko@sntech.de> wrote:
> > > The need to know the number of array elements in a property is
> > > a common pattern. To prevent duplication of open-coded implementations
> > > add a helper static function that also centralises strict sanity
> > > checking and DTB format details, as well as a set of wrapper functions
> > > for u8, u16, u32 and u64.
> > >
> > > Suggested-by: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> > > Signed-off-by: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
> > > ---
> >
> > Looks good. Do you plan to convert some users to use this?
>
> I'll take that as an acked-by. Merged, thanks.
before you taking this patch, I was planning on simply sending this as part of
my rockchip-smp series - as I'm currently the only user of it :-) .
This going through your tree is most likely the better way, but now I need it
to somehow make its way into arm-soc too ... I guess some sort of stable
branch arm-soc could pull?
Thanks
Heiko
--
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 V3] net/dt: Add support for overriding phy configuration from device tree
From: Florian Fainelli @ 2014-02-04 19:01 UTC (permalink / raw)
To: Ben Hutchings
Cc: Matthew Garrett, netdev,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Kishon Vijay Abraham I
In-Reply-To: <1390145654.16433.102.camel-nDn/Rdv9kqW9Jme8/bJn5UCKIB8iOfG2tUK59QYPAWc@public.gmane.org>
2014-01-19 Ben Hutchings <ben-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>:
> On Fri, 2014-01-17 at 17:57 -0500, Matthew Garrett wrote:
>> Some hardware may be broken in interesting and board-specific ways, such
>> that various bits of functionality don't work. This patch provides a
>> mechanism for overriding mii registers during init based on the contents of
>> the device tree data, allowing board-specific fixups without having to
>> pollute generic code.
> [...]
>> --- a/Documentation/devicetree/bindings/net/phy.txt
>> +++ b/Documentation/devicetree/bindings/net/phy.txt
>> @@ -23,6 +23,21 @@ Optional Properties:
>> assume clause 22. The compatible list may also contain other
>> elements.
>>
>> +The following properties may be added to either the phy node or the parent
>> +ethernet device. If not present, the hardware defaults will be used.
>> +
>> +- phy-mii-advertise-10half: 1 to advertise half-duplex 10MBit, 0 to disable
>> +- phy-mii-advertise-10full: 1 to advertise full-duplex 10MBit, 0 to disable
>> +- phy-mii-advertise-100half: 1 to advertise half-duplex 100MBit, 0 to disable
>> +- phy-mii-advertise-100full: 1 to advertise full-duplex 100MBit, 0 to disable
>> +- phy-mii-advertise-100base4: 1 to advertise 100base4, 0 to disable
>> +- phy-mii-advertise-1000half: 1 to advertise half-duplex 1000MBit, 0 to disable
>> +- phy-mii-advertise-1000full: 1 to advertise full-duplex 1000MBit, 0 to disable
>
> Are these really all needed? Apparently there is a standard 'max-speed'
> property on Ethernet devices already, which I think is probably
> sufficient to express the actual restrictions of some boards.
This is what I think as well. Maybe there is the need for something
more fine-grained, although I really doubt it.
>
>> +- phy-mii-manual-master: 1 to enable manual master/slave configuration, 0
>> + to disable manual master/slave configuration
> [...]
>
> Although the standard calls this 'manual', if it's set in the DT it
> won't really be a manual setting. The description should probably
> clarify that.
>
> I think the name should include 'master-slave' or 'clock-role' rather
> than just 'master', as currently it suggests only the master role can be
> forced.
Right, and this would match what 802.3-2008, Section 22.2.4.3.7 mentions.
>
> Ben.
>
> --
> Ben Hutchings
> friends: People who know you well, but like you anyway.
--
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 v3 3/5] ASoC: tda998x: add DT documentation of the tda998x CODEC
From: Jean-Francois Moine @ 2014-02-04 19:02 UTC (permalink / raw)
To: Mark Brown
Cc: devicetree, alsa-devel, Russell King - ARM Linux, linux-kernel,
dri-devel, linux-arm-kernel
In-Reply-To: <20140204181213.GO22609@sirena.org.uk>
On Tue, 4 Feb 2014 18:12:13 +0000
Mark Brown <broonie@kernel.org> wrote:
> On Sat, Feb 01, 2014 at 05:48:49PM +0100, Jean-Francois Moine wrote:
>
> > + - compatible: must be "nxp,tda998x-codec".
>
> It's not clear to me why there's a separate compatible here - as far as
> I can see this can only appear as part of one of these devices and
> there's no addressing or other information that'd account for chip
> variation so I'd not expect to need to bind this independently of the
> parent.
If there is no 'compatible', the CODEC module is not loaded, and, when
the module is in the core, no CODEC device can be created from the DT.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ 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