Re: Tearing down DMA transfer setup after DMA client has finished

On 09/12/16 07:59, Vinod Koul wrote: > On Thu, Dec 08, 2016 at 04:48:18PM +, Måns Rullgård wrote: >> Vinod Koul writes: >> >>> To make it efficient, disregarding your Sbox HW issue, the solution is >>> virtual channels. You can delink physical channels and virtual

Re: Tearing down DMA transfer setup after DMA client has finished

On 09/12/16 07:59, Vinod Koul wrote: > On Thu, Dec 08, 2016 at 04:48:18PM +, Måns Rullgård wrote: >> Vinod Koul writes: >> >>> To make it efficient, disregarding your Sbox HW issue, the solution is >>> virtual channels. You can delink physical channels and virtual channels. If >>> one has SW

Re: [PATCH v3] add equivalent of BIT(x) for bitfields

On 07/12/16 15:02, Jakub Kicinski wrote: > On Wed, 7 Dec 2016 14:51:36 +0100, Sebastian Frias wrote: >> On 07/12/16 13:38, Jakub Kicinski wrote: >>> On Wed, 7 Dec 2016 12:23:56 +0100, Sebastian Frias wrote: >>>> On 07/12/16 12:05, Jakub Kicinski wrote: >>&

Re: [PATCH v3] add equivalent of BIT(x) for bitfields

On 07/12/16 15:02, Jakub Kicinski wrote: > On Wed, 7 Dec 2016 14:51:36 +0100, Sebastian Frias wrote: >> On 07/12/16 13:38, Jakub Kicinski wrote: >>> On Wed, 7 Dec 2016 12:23:56 +0100, Sebastian Frias wrote: >>>> On 07/12/16 12:05, Jakub Kicinski wrote: >>&

Re: [PATCH v3] add equivalent of BIT(x) for bitfields

On 07/12/16 13:38, Jakub Kicinski wrote: > On Wed, 7 Dec 2016 12:23:56 +0100, Sebastian Frias wrote: >> On 07/12/16 12:05, Jakub Kicinski wrote: >>> On Wed, 7 Dec 2016 11:00:57 +0100, Sebastian Frias wrote: >>>> On 07/12/16 09:42, Kalle Valo wrote: >>&

Re: [PATCH v3] add equivalent of BIT(x) for bitfields

On 07/12/16 13:38, Jakub Kicinski wrote: > On Wed, 7 Dec 2016 12:23:56 +0100, Sebastian Frias wrote: >> On 07/12/16 12:05, Jakub Kicinski wrote: >>> On Wed, 7 Dec 2016 11:00:57 +0100, Sebastian Frias wrote: >>>> On 07/12/16 09:42, Kalle Valo wrote:

Re: [PATCH v3] add equivalent of BIT(x) for bitfields

On 07/12/16 12:05, Jakub Kicinski wrote: > On Wed, 7 Dec 2016 11:00:57 +0100, Sebastian Frias wrote: >> On 07/12/16 09:42, Kalle Valo wrote: >>> Sebastian Frias <s...@laposte.net> writes: >>> >>>> Introduce GENVALUE(msb, lsb, value) macro to ease

Re: [PATCH v3] add equivalent of BIT(x) for bitfields

On 07/12/16 12:05, Jakub Kicinski wrote: > On Wed, 7 Dec 2016 11:00:57 +0100, Sebastian Frias wrote: >> On 07/12/16 09:42, Kalle Valo wrote: >>> Sebastian Frias writes: >>> >>>> Introduce GENVALUE(msb, lsb, value) macro to ease dealing with >>

Re: [PATCH v3] add equivalent of BIT(x) for bitfields

On 07/12/16 09:42, Kalle Valo wrote: > Sebastian Frias <s...@laposte.net> writes: > >> Introduce GENVALUE(msb, lsb, value) macro to ease dealing with >> continuous bitfields, just as BIT(x) does for single bits. >> >> GENVALUE_ULL(msb, lsb, value) macro is als

Re: [PATCH v3] add equivalent of BIT(x) for bitfields

On 07/12/16 09:42, Kalle Valo wrote: > Sebastian Frias writes: > >> Introduce GENVALUE(msb, lsb, value) macro to ease dealing with >> continuous bitfields, just as BIT(x) does for single bits. >> >> GENVALUE_ULL(msb, lsb, value) macro is also added. >> &

[PATCH v4] add macros for bitfield manipulation ala GENMASK

= BITFIELD_EXTRACT(a, 19, 12); => b = 0xa5; BITFIELD_INSERT(a, 19, 12, 0xff5a); => a = 0x1115a000; Signed-off-by: Sebastian Frias <s...@laposte.net> Link: https://marc.info/?l=linux-kernel=148094498711000=2 --- Change in v2: - rename the macro to GENVALUE as proposed by Linus - longer comm

[PATCH v4] add macros for bitfield manipulation ala GENMASK

= BITFIELD_EXTRACT(a, 19, 12); => b = 0xa5; BITFIELD_INSERT(a, 19, 12, 0xff5a); => a = 0x1115a000; Signed-off-by: Sebastian Frias Link: https://marc.info/?l=linux-kernel=148094498711000=2 --- Change in v2: - rename the macro to GENVALUE as proposed by Linus - longer comment attempts to show us

[PATCH v5] add macros for bitfield manipulation "à la" GENMASK

gt; 'b = 0xa5' BITFIELD_INSERT(a, 19, 12, 0xff5a); => 'a = 0x1115a000' Signed-off-by: Sebastian Frias <s...@laposte.net> Link: https://marc.info/?l=linux-kernel=148094498711000=2 --- Change in v2: - rename the macro to GENVALUE as proposed by Linus - longer comment attempts t

[PATCH v5] add macros for bitfield manipulation "à la" GENMASK

gt; 'b = 0xa5' BITFIELD_INSERT(a, 19, 12, 0xff5a); => 'a = 0x1115a000' Signed-off-by: Sebastian Frias Link: https://marc.info/?l=linux-kernel=148094498711000=2 --- Change in v2: - rename the macro to GENVALUE as proposed by Linus - longer comment attempts to show use case for the macro as

Re: [PATCH] bitops: add equivalent of BIT(x) for bitfields

Hi Geert, On 06/12/16 12:12, Geert Uytterhoeven wrote: >>> ... which means "generate a value"?? >>> >> >> Yes. >> Although I'm not sure if I understood the essence of your point. >> Are you suggesting that the name should be GENERATE_A_VALUE? > > No. I mean that "value" is a way too generic

Re: [PATCH] bitops: add equivalent of BIT(x) for bitfields

Hi Geert, On 06/12/16 12:12, Geert Uytterhoeven wrote: >>> ... which means "generate a value"?? >>> >> >> Yes. >> Although I'm not sure if I understood the essence of your point. >> Are you suggesting that the name should be GENERATE_A_VALUE? > > No. I mean that "value" is a way too generic

Re: Adding a .platform_init callback to sdhci_arasan_ops

Hi, On 05/12/16 17:30, Doug Anderson wrote: > > AKA: you are setting up various "corecfg" stuff that's documented in > the generic Arasan docs. Others SDHCI-Arasan implementations might > want to set the same things, but those values may be stored elsewhere > for them. Exactly, that is what

Re: Adding a .platform_init callback to sdhci_arasan_ops

Hi, On 05/12/16 17:30, Doug Anderson wrote: > > AKA: you are setting up various "corecfg" stuff that's documented in > the generic Arasan docs. Others SDHCI-Arasan implementations might > want to set the same things, but those values may be stored elsewhere > for them. Exactly, that is what

Re: [PATCH] bitops: add equivalent of BIT(x) for bitfields

On 06/12/16 11:42, Geert Uytterhoeven wrote: > On Tue, Dec 6, 2016 at 11:31 AM, Sebastian Frias <s...@laposte.net> wrote: >> On 05/12/16 18:48, Geert Uytterhoeven wrote: >>> On Mon, Dec 5, 2016 at 2:36 PM, Sebastian Frias <s...@laposte.net> wrote: >>>> In

Re: [PATCH] bitops: add equivalent of BIT(x) for bitfields

On 06/12/16 11:42, Geert Uytterhoeven wrote: > On Tue, Dec 6, 2016 at 11:31 AM, Sebastian Frias wrote: >> On 05/12/16 18:48, Geert Uytterhoeven wrote: >>> On Mon, Dec 5, 2016 at 2:36 PM, Sebastian Frias wrote: >>>> Introduce SETBITFIELD(msb, lsb, value) macro to eas

Re: [PATCH v2] add equivalent of BIT(x) for bitfields

On 05/12/16 19:23, Linus Torvalds wrote: > On Mon, Dec 5, 2016 at 9:49 AM, Sebastian Frias <s...@laposte.net> wrote: >> Introduce GENVALUE(msb, lsb, value) macro to ease dealing with >> continuous bitfields, just as BIT(x) does for single bits. > > Oh, and lo

Re: [PATCH v2] add equivalent of BIT(x) for bitfields

On 05/12/16 19:23, Linus Torvalds wrote: > On Mon, Dec 5, 2016 at 9:49 AM, Sebastian Frias wrote: >> Introduce GENVALUE(msb, lsb, value) macro to ease dealing with >> continuous bitfields, just as BIT(x) does for single bits. > > Oh, and looking at the implementation, this i

Re: [PATCH] bitops: add equivalent of BIT(x) for bitfields

On 05/12/16 18:48, Geert Uytterhoeven wrote: > On Mon, Dec 5, 2016 at 2:36 PM, Sebastian Frias <s...@laposte.net> wrote: >> Introduce SETBITFIELD(msb, lsb, value) macro to ease dealing with >> continuous bitfields, just as BIT(x) does for single bits. > > If it's

Re: [PATCH] bitops: add equivalent of BIT(x) for bitfields

On 05/12/16 18:48, Geert Uytterhoeven wrote: > On Mon, Dec 5, 2016 at 2:36 PM, Sebastian Frias wrote: >> Introduce SETBITFIELD(msb, lsb, value) macro to ease dealing with >> continuous bitfields, just as BIT(x) does for single bits. > > If it's a bitfield, why not calli

[PATCH v3] add equivalent of BIT(x) for bitfields

|= GENVALUE(19, 12, 0x5a); now 'val = 0x1115a000' Signed-off-by: Sebastian Frias <s...@laposte.net> Link: https://marc.info/?l=linux-kernel=148094498711000=2 --- Change in v2: - rename the macro to GENVALUE as proposed by Linus - longer comment attempts to show use case for the macro as pr

[PATCH v3] add equivalent of BIT(x) for bitfields

|= GENVALUE(19, 12, 0x5a); now 'val = 0x1115a000' Signed-off-by: Sebastian Frias Link: https://marc.info/?l=linux-kernel=148094498711000=2 --- Change in v2: - rename the macro to GENVALUE as proposed by Linus - longer comment attempts to show use case for the macro as proposed by Borislav Change

[PATCH v2] add equivalent of BIT(x) for bitfields

|= GENVALUE(19, 12, 0x5a); now 'val = 0x1115a000' Signed-off-by: Sebastian Frias <s...@laposte.net> --- Change in v2: - rename the macro to GENVALUE as proposed by Linus - longer comment attempts to show use case for the macro as proposed by Borislav --- include/linux/bitops.

[PATCH v2] add equivalent of BIT(x) for bitfields

|= GENVALUE(19, 12, 0x5a); now 'val = 0x1115a000' Signed-off-by: Sebastian Frias --- Change in v2: - rename the macro to GENVALUE as proposed by Linus - longer comment attempts to show use case for the macro as proposed by Borislav --- include/linux/bitops.h | 14 ++ 1 file changed

Re: [PATCH] bitops: add equivalent of BIT(x) for bitfields

On 05/12/16 18:13, Linus Torvalds wrote: > On Mon, Dec 5, 2016 at 5:36 AM, Sebastian Frias <s...@laposte.net> wrote: >> Introduce SETBITFIELD(msb, lsb, value) macro to ease dealing with >> continuous bitfields, just as BIT(x) does for single bits. >> >> SETBI

Re: [PATCH] bitops: add equivalent of BIT(x) for bitfields

On 05/12/16 18:13, Linus Torvalds wrote: > On Mon, Dec 5, 2016 at 5:36 AM, Sebastian Frias wrote: >> Introduce SETBITFIELD(msb, lsb, value) macro to ease dealing with >> continuous bitfields, just as BIT(x) does for single bits. >> >> SETBITFIELD_ULL(msb, lsb,

Re: [PATCH] bitops: add equivalent of BIT(x) for bitfields

On 05/12/16 16:34, Borislav Petkov wrote: > On Mon, Dec 05, 2016 at 02:36:07PM +0100, Sebastian Frias wrote: >> + * Equivalent of BIT(x) but for contiguous bitfields >> + * SETBITFIELD(1, 0,0xff) = 0x0003 >> + * SETBITFIELD(3, 0,0xff) = 0x000f >> + * SETBITFI

Re: [PATCH] bitops: add equivalent of BIT(x) for bitfields

On 05/12/16 16:34, Borislav Petkov wrote: > On Mon, Dec 05, 2016 at 02:36:07PM +0100, Sebastian Frias wrote: >> + * Equivalent of BIT(x) but for contiguous bitfields >> + * SETBITFIELD(1, 0,0xff) = 0x0003 >> + * SETBITFIELD(3, 0,0xff) = 0x000f >> + * SETBITFI

[PATCH] bitops: add equivalent of BIT(x) for bitfields

Introduce SETBITFIELD(msb, lsb, value) macro to ease dealing with continuous bitfields, just as BIT(x) does for single bits. SETBITFIELD_ULL(msb, lsb, value) macro is also added. Signed-off-by: Sebastian Frias <s...@laposte.net> --- Code protected with "#ifdef __KERNEL__" j

[PATCH] bitops: add equivalent of BIT(x) for bitfields

Introduce SETBITFIELD(msb, lsb, value) macro to ease dealing with continuous bitfields, just as BIT(x) does for single bits. SETBITFIELD_ULL(msb, lsb, value) macro is also added. Signed-off-by: Sebastian Frias --- Code protected with "#ifdef __KERNEL__" just as the BIT(x) macros. I

Re: Adding a .platform_init callback to sdhci_arasan_ops

Hi Doug, On 28/11/16 19:02, Doug Anderson wrote: > Hi, > > On Mon, Nov 28, 2016 at 5:28 AM, Sebastian Frias <s...@laposte.net> wrote: >> +static void sdhci_tango4_platform_init(struct sdhci_host *host) >> +{ >> + printk("%s\n", __func__); >

Re: Adding a .platform_init callback to sdhci_arasan_ops

Hi Doug, On 28/11/16 19:02, Doug Anderson wrote: > Hi, > > On Mon, Nov 28, 2016 at 5:28 AM, Sebastian Frias wrote: >> +static void sdhci_tango4_platform_init(struct sdhci_host *host) >> +{ >> + printk("%s\n", __func__); >> + >> +

Re: Adding a .platform_init callback to sdhci_arasan_ops

Hi Doug, On 28/11/16 18:46, Doug Anderson wrote: > Hi, > > On Mon, Nov 28, 2016 at 6:39 AM, Sebastian Frias <s...@laposte.net> wrote: >>> I will try to send another patch with what a different approach >>> >> >> Here's a different approach (I just t

Re: Adding a .platform_init callback to sdhci_arasan_ops

Hi Doug, On 28/11/16 18:46, Doug Anderson wrote: > Hi, > > On Mon, Nov 28, 2016 at 6:39 AM, Sebastian Frias wrote: >>> I will try to send another patch with what a different approach >>> >> >> Here's a different approach (I just tested that it built,

Re: Adding a .platform_init callback to sdhci_arasan_ops

On 28/11/16 14:28, Sebastian Frias wrote: > On 28/11/16 12:44, Adrian Hunter wrote: >> On 28/11/16 13:20, Sebastian Frias wrote: >>> Hi Adrian, >>> >>> On 28/11/16 11:30, Adrian Hunter wrote: >>>> On 28/11/16 09:32, Michal Simek wrote: >>>

Re: Adding a .platform_init callback to sdhci_arasan_ops

On 28/11/16 14:28, Sebastian Frias wrote: > On 28/11/16 12:44, Adrian Hunter wrote: >> On 28/11/16 13:20, Sebastian Frias wrote: >>> Hi Adrian, >>> >>> On 28/11/16 11:30, Adrian Hunter wrote: >>>> On 28/11/16 09:32, Michal Simek wrote: >>>

Re: Adding a .platform_init callback to sdhci_arasan_ops

On 28/11/16 12:44, Adrian Hunter wrote: > On 28/11/16 13:20, Sebastian Frias wrote: >> Hi Adrian, >> >> On 28/11/16 11:30, Adrian Hunter wrote: >>> On 28/11/16 09:32, Michal Simek wrote: >>>> +Sai for Xilinx perspective. >>>> >

Re: Adding a .platform_init callback to sdhci_arasan_ops

On 28/11/16 12:44, Adrian Hunter wrote: > On 28/11/16 13:20, Sebastian Frias wrote: >> Hi Adrian, >> >> On 28/11/16 11:30, Adrian Hunter wrote: >>> On 28/11/16 09:32, Michal Simek wrote: >>>> +Sai for Xilinx perspective. >>>> >

Re: Adding a .platform_init callback to sdhci_arasan_ops

Hi Adrian, On 28/11/16 11:30, Adrian Hunter wrote: > On 28/11/16 09:32, Michal Simek wrote: >> +Sai for Xilinx perspective. >> >> On 25.11.2016 16:24, Sebastian Frias wrote: >>> Hi, >>> >>> When using the Arasan SDHCI HW IP, there is a set of param

Re: Adding a .platform_init callback to sdhci_arasan_ops

Hi Adrian, On 28/11/16 11:30, Adrian Hunter wrote: > On 28/11/16 09:32, Michal Simek wrote: >> +Sai for Xilinx perspective. >> >> On 25.11.2016 16:24, Sebastian Frias wrote: >>> Hi, >>> >>> When using the Arasan SDHCI HW IP, there is a set of param

Adding a .platform_init callback to sdhci_arasan_ops

Hi, When using the Arasan SDHCI HW IP, there is a set of parameters called "Hardware initialized registers" (Table 7, Section "Pin Signals", page 56 of Arasan "SD3.0/SDIO3.0/eMMC4.4 AHB Host Controller", revision 6.0 document) In some platforms those signals are connected to registers that need

Adding a .platform_init callback to sdhci_arasan_ops

Hi, When using the Arasan SDHCI HW IP, there is a set of parameters called "Hardware initialized registers" (Table 7, Section "Pin Signals", page 56 of Arasan "SD3.0/SDIO3.0/eMMC4.4 AHB Host Controller", revision 6.0 document) In some platforms those signals are connected to registers that need

Re: [PATCH 1/2] net: ethernet: nb8800: Do not apply TX delay at MAC level

On 11/09/2016 06:03 PM, Florian Fainelli wrote: > On 11/09/2016 05:02 AM, Sebastian Frias wrote: >> On 11/04/2016 05:49 PM, Måns Rullgård wrote: >>>>> But when doing so, both the Atheros 8035 and the Aurora NB8800 drivers >>>>> will apply the delay. >

Re: [PATCH 1/2] net: ethernet: nb8800: Do not apply TX delay at MAC level

On 11/09/2016 06:03 PM, Florian Fainelli wrote: > On 11/09/2016 05:02 AM, Sebastian Frias wrote: >> On 11/04/2016 05:49 PM, Måns Rullgård wrote: >>>>> But when doing so, both the Atheros 8035 and the Aurora NB8800 drivers >>>>> will apply the delay. >

Re: Is Documentation/networking/phy.txt still up-to-date?

On 11/09/2016 06:07 PM, Florian Fainelli wrote: > On 11/09/2016 05:24 AM, Sebastian Frias wrote: >> Hi, >> >> Documentation/networking/phy.txt discusses phy_connect and states that: >> >> "... >> >> interface is a u32 which specifies t

Re: Is Documentation/networking/phy.txt still up-to-date?

On 11/09/2016 06:07 PM, Florian Fainelli wrote: > On 11/09/2016 05:24 AM, Sebastian Frias wrote: >> Hi, >> >> Documentation/networking/phy.txt discusses phy_connect and states that: >> >> "... >> >> interface is a u32 which specifies t

Is Documentation/networking/phy.txt still up-to-date?

Hi, Documentation/networking/phy.txt discusses phy_connect and states that: "... interface is a u32 which specifies the connection type used between the controller and the PHY. Examples are GMII, MII, RGMII, and SGMII. For a full list, see include/linux/phy.h Now just make sure that

Is Documentation/networking/phy.txt still up-to-date?

Hi, Documentation/networking/phy.txt discusses phy_connect and states that: "... interface is a u32 which specifies the connection type used between the controller and the PHY. Examples are GMII, MII, RGMII, and SGMII. For a full list, see include/linux/phy.h Now just make sure that

Re: [PATCH 1/2] net: ethernet: nb8800: Do not apply TX delay at MAC level

On 11/04/2016 05:49 PM, Måns Rullgård wrote: >>> But when doing so, both the Atheros 8035 and the Aurora NB8800 drivers >>> will apply the delay. >>> >>> I think a better way of dealing with this is that both, PHY and MAC >>> drivers exchange information so that the delay is applied only once. >>

Re: [PATCH 1/2] net: ethernet: nb8800: Do not apply TX delay at MAC level

On 11/04/2016 05:49 PM, Måns Rullgård wrote: >>> But when doing so, both the Atheros 8035 and the Aurora NB8800 drivers >>> will apply the delay. >>> >>> I think a better way of dealing with this is that both, PHY and MAC >>> drivers exchange information so that the delay is applied only once. >>

Re: [PATCH v3 2/2] net: ethernet: nb8800: handle all RGMII definitions

Hi Måns, On 11/05/2016 01:58 PM, Måns Rullgård wrote: >> if (gigabit) { >> -if (priv->phy_mode == PHY_INTERFACE_MODE_RGMII) >> +if (phy_interface_is_rgmii(phydev)) >> mac_mode |= RGMII_MODE; >> >> mac_mode |= GMAC_MODE; > > As I said

Re: [PATCH v3 2/2] net: ethernet: nb8800: handle all RGMII definitions

Hi Måns, On 11/05/2016 01:58 PM, Måns Rullgård wrote: >> if (gigabit) { >> -if (priv->phy_mode == PHY_INTERFACE_MODE_RGMII) >> +if (phy_interface_is_rgmii(phydev)) >> mac_mode |= RGMII_MODE; >> >> mac_mode |= GMAC_MODE; > > As I said

Re: [PATCH v2 2/2 ] net: ethernet: nb8800: handle all RGMII definitions

Hi David, On 11/04/2016 06:54 PM, David Miller wrote: > From: Sebastian Frias <s...@laposte.net> > Date: Fri, 4 Nov 2016 18:02:15 +0100 > >> Commit a999589ccaae ("phylib: add RGMII-ID interface mode definition") >> and commit 7d400a4c5897 ("phylib: add

Re: [PATCH v2 2/2 ] net: ethernet: nb8800: handle all RGMII definitions

Hi David, On 11/04/2016 06:54 PM, David Miller wrote: > From: Sebastian Frias > Date: Fri, 4 Nov 2016 18:02:15 +0100 > >> Commit a999589ccaae ("phylib: add RGMII-ID interface mode definition") >> and commit 7d400a4c5897 ("phylib: add PHY interface modes for

[PATCH v3 2/2] net: ethernet: nb8800: handle all RGMII definitions

FACE_MODE_RGMII_TXID to deal with internal delays. Those are all RGMII modes (1Gbit) and must be considered that way when setting the MAC mode or the pad mode for the HW to work properly. Signed-off-by: Sebastian Frias <s...@laposte.net> --- drivers/net/ethernet/aurora/nb8800.c | 8 1

[PATCH v3 2/2] net: ethernet: nb8800: handle all RGMII definitions

FACE_MODE_RGMII_TXID to deal with internal delays. Those are all RGMII modes (1Gbit) and must be considered that way when setting the MAC mode or the pad mode for the HW to work properly. Signed-off-by: Sebastian Frias --- drivers/net/ethernet/aurora/nb8800.c | 8 1 file changed, 4 insert

[PATCH v3 1/2] net: ethernet: nb8800: Do not apply TX delay at MAC level

The delay can be applied at PHY or MAC level, but since PHY drivers will apply the delay at PHY level when using one of the "internal delay" declinations of RGMII mode (like PHY_INTERFACE_MODE_RGMII_TXID), applying it again at MAC level causes issues. Signed-off-by: Sebastia

[PATCH v3 1/2] net: ethernet: nb8800: Do not apply TX delay at MAC level

The delay can be applied at PHY or MAC level, but since PHY drivers will apply the delay at PHY level when using one of the "internal delay" declinations of RGMII mode (like PHY_INTERFACE_MODE_RGMII_TXID), applying it again at MAC level causes issues. Signed-off-by: Sebastian Frias --

[PATCH v3 0/2] net: ethernet: nb8800: Do not apply TX delay at MAC level

This is v3 of the series, it fixes formatting issues of v2. In v2 of the series, only the second patch: "net: ethernet: nb8800: handle all RGMII definitions" is modified to account for Florian's suggestion. Sebastian Frias (2): net: ethernet: nb8800: Do not apply TX delay at MAC l

[PATCH v3 0/2] net: ethernet: nb8800: Do not apply TX delay at MAC level

This is v3 of the series, it fixes formatting issues of v2. In v2 of the series, only the second patch: "net: ethernet: nb8800: handle all RGMII definitions" is modified to account for Florian's suggestion. Sebastian Frias (2): net: ethernet: nb8800: Do not apply TX delay at MAC l

[PATCH v2 2/2] net: ethernet: nb8800: handle all RGMII definitions

FACE_MODE_RGMII_TXID to deal with internal delays. Those are all RGMII modes (1Gbit) and must be considered that way when setting the MAC mode or the pad mode for the HW to work properly. Signed-off-by: Sebastian Frias <s...@laposte.net> --- drivers/net/ethernet/aurora/nb8800.c | 8 1

[PATCH v2 2/2] net: ethernet: nb8800: handle all RGMII definitions

FACE_MODE_RGMII_TXID to deal with internal delays. Those are all RGMII modes (1Gbit) and must be considered that way when setting the MAC mode or the pad mode for the HW to work properly. Signed-off-by: Sebastian Frias --- drivers/net/ethernet/aurora/nb8800.c | 8 1 file changed, 4 insert

[PATCH v2 1/2] net: ethernet: nb8800: Do not apply TX delay at MAC level

The delay can be applied at PHY or MAC level, but since PHY drivers will apply the delay at PHY level when using one of the "internal delay" declinations of RGMII mode (like PHY_INTERFACE_MODE_RGMII_TXID), applying it again at MAC level causes issues. Signed-off-by: Sebastia

[PATCH v2 1/2] net: ethernet: nb8800: Do not apply TX delay at MAC level

The delay can be applied at PHY or MAC level, but since PHY drivers will apply the delay at PHY level when using one of the "internal delay" declinations of RGMII mode (like PHY_INTERFACE_MODE_RGMII_TXID), applying it again at MAC level causes issues. Signed-off-by: Sebastian Frias -

[PATCH v2 0/2] net: ethernet: nb8800: Do not apply TX delay at MAC level

This is v2 of the series, only the second patch: "net: ethernet: nb8800: handle all RGMII definitions" is modified to account for Florian's suggestion. Sebastian Frias (2): net: ethernet: nb8800: Do not apply TX delay at MAC level net: ethernet: nb8800: handle all RGMII definitions

[PATCH v2 0/2] net: ethernet: nb8800: Do not apply TX delay at MAC level

This is v2 of the series, only the second patch: "net: ethernet: nb8800: handle all RGMII definitions" is modified to account for Florian's suggestion. Sebastian Frias (2): net: ethernet: nb8800: Do not apply TX delay at MAC level net: ethernet: nb8800: handle all RGMII definitions

[PATCH v2 2/2 ] net: ethernet: nb8800: handle all RGMII definitions

FACE_MODE_RGMII_TXID to deal with internal delays. Those are all RGMII modes (1Gbit) and must be considered that way when setting the MAC mode or the pad mode for the HW to work properly. Signed-off-by: Sebastian Frias <s...@laposte.net> --- drivers/net/ethernet/aurora/nb8800.c | 8 1

[PATCH v2 2/2 ] net: ethernet: nb8800: handle all RGMII definitions

FACE_MODE_RGMII_TXID to deal with internal delays. Those are all RGMII modes (1Gbit) and must be considered that way when setting the MAC mode or the pad mode for the HW to work properly. Signed-off-by: Sebastian Frias --- drivers/net/ethernet/aurora/nb8800.c | 8 1 file changed, 4 insert

Re: [PATCH 2/2] net: ethernet: nb8800: handle all RGMII declinations

On 11/04/2016 05:23 PM, Florian Fainelli wrote: > > > On 11/04/2016 08:05 AM, Sebastian Frias wrote: >> Commit a999589ccaae ("phylib: add RGMII-ID interface mode definition") >> and commit 7d400a4c5897 ("phylib: add PHY interface modes for internal >>

Re: [PATCH 2/2] net: ethernet: nb8800: handle all RGMII declinations

On 11/04/2016 05:23 PM, Florian Fainelli wrote: > > > On 11/04/2016 08:05 AM, Sebastian Frias wrote: >> Commit a999589ccaae ("phylib: add RGMII-ID interface mode definition") >> and commit 7d400a4c5897 ("phylib: add PHY interface modes for internal >>

Re: [PATCH 1/2] net: ethernet: nb8800: Do not apply TX delay at MAC level

Hi Måns, On 11/04/2016 04:18 PM, Måns Rullgård wrote: > Sebastian Frias <s...@laposte.net> writes: > >> The delay can be applied at PHY or MAC level, but since >> PHY drivers will apply the delay at PHY level when using >> one of the "internal delay&q

Re: [PATCH 1/2] net: ethernet: nb8800: Do not apply TX delay at MAC level

Hi Måns, On 11/04/2016 04:18 PM, Måns Rullgård wrote: > Sebastian Frias writes: > >> The delay can be applied at PHY or MAC level, but since >> PHY drivers will apply the delay at PHY level when using >> one of the "internal delay" d

Re: [PATCH 1/2] net: ethernet: nb8800: Do not apply TX delay at MAC level

Hi Andrew, On 11/04/2016 04:11 PM, Andrew Lunn wrote: > On Fri, Nov 04, 2016 at 04:02:24PM +0100, Sebastian Frias wrote: >> The delay can be applied at PHY or MAC level, but since >> PHY drivers will apply the delay at PHY level when using >> one of the "internal delay&q

Re: [PATCH 1/2] net: ethernet: nb8800: Do not apply TX delay at MAC level

Hi Andrew, On 11/04/2016 04:11 PM, Andrew Lunn wrote: > On Fri, Nov 04, 2016 at 04:02:24PM +0100, Sebastian Frias wrote: >> The delay can be applied at PHY or MAC level, but since >> PHY drivers will apply the delay at PHY level when using >> one of the "internal delay&q

[PATCH 2/2] net: ethernet: nb8800: handle all RGMII declinations

FACE_MODE_RGMII_TXID to deal with internal delays. Those are all RGMII modes (1Gbit) and must be considered that way when setting the MAC Mode or the Pads Mode for the HW to work properly. Signed-off-by: Sebastian Frias <s...@laposte.net> --- drivers/net/ethernet/aurora/nb8800.c | 10 +++

[PATCH 2/2] net: ethernet: nb8800: handle all RGMII declinations

FACE_MODE_RGMII_TXID to deal with internal delays. Those are all RGMII modes (1Gbit) and must be considered that way when setting the MAC Mode or the Pads Mode for the HW to work properly. Signed-off-by: Sebastian Frias --- drivers/net/ethernet/aurora/nb8800.c | 10 ++ 1 file changed

[PATCH 1/2] net: ethernet: nb8800: Do not apply TX delay at MAC level

The delay can be applied at PHY or MAC level, but since PHY drivers will apply the delay at PHY level when using one of the "internal delay" declinations of RGMII mode (like PHY_INTERFACE_MODE_RGMII_TXID), applying it again at MAC level causes issues. Signed-off-by: Sebastia

[PATCH 1/2] net: ethernet: nb8800: Do not apply TX delay at MAC level

The delay can be applied at PHY or MAC level, but since PHY drivers will apply the delay at PHY level when using one of the "internal delay" declinations of RGMII mode (like PHY_INTERFACE_MODE_RGMII_TXID), applying it again at MAC level causes issues. Signed-off-by: Sebastian Frias --

Re: Disabling an interrupt in the handler locks the system up

Hi Thomas, On 10/24/2016 06:55 PM, Thomas Gleixner wrote: > On Mon, 24 Oct 2016, Mason wrote: >> >> For the record, setting the IRQ_DISABLE_UNLAZY flag for this device >> makes the system lock-up disappear. > > The way how lazy irq disabling works is: > > 1) Interrupt is marked disabled in

Re: Disabling an interrupt in the handler locks the system up

Hi Thomas, On 10/24/2016 06:55 PM, Thomas Gleixner wrote: > On Mon, 24 Oct 2016, Mason wrote: >> >> For the record, setting the IRQ_DISABLE_UNLAZY flag for this device >> makes the system lock-up disappear. > > The way how lazy irq disabling works is: > > 1) Interrupt is marked disabled in

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/13/2016 04:51 PM, Mark Rutland wrote: > Hi, > > On Tue, Sep 13, 2016 at 04:22:09PM +0200, Sebastian Frias wrote: >> On 09/13/2016 03:12 PM, Mark Rutland wrote: > > [context was deleted, TL;DR: binding review is necessary, and takes > effort, regard

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/13/2016 04:51 PM, Mark Rutland wrote: > Hi, > > On Tue, Sep 13, 2016 at 04:22:09PM +0200, Sebastian Frias wrote: >> On 09/13/2016 03:12 PM, Mark Rutland wrote: > > [context was deleted, TL;DR: binding review is necessary, and takes > effort, regard

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/13/2016 05:47 PM, Mark Rutland wrote: >>> If you believe that the bindings don't matter, then there is absolutely >>> no reason for them to exist in the first place. >>> >>> If those binding matter to *anyone*, then those collating the bindings >>> have some responsibility of

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/13/2016 05:47 PM, Mark Rutland wrote: >>> If you believe that the bindings don't matter, then there is absolutely >>> no reason for them to exist in the first place. >>> >>> If those binding matter to *anyone*, then those collating the bindings >>> have some responsibility of

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/13/2016 03:12 PM, Mark Rutland wrote: >> Exactly, that is why I was thinking it would take less "review" time. >> Indeed, if there is no driver, why would it matter what those bindings >> are? > > If you believe that the bindings don't matter, then there is absolutely > no reason

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/13/2016 03:12 PM, Mark Rutland wrote: >> Exactly, that is why I was thinking it would take less "review" time. >> Indeed, if there is no driver, why would it matter what those bindings >> are? > > If you believe that the bindings don't matter, then there is absolutely > no reason

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/13/2016 03:12 PM, Mark Rutland wrote: >> Exactly, that is why I was thinking it would take less "review" time. >> Indeed, if there is no driver, why would it matter what those bindings >> are? > > If you believe that the bindings don't matter, then there is absolutely > no reason

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/13/2016 03:12 PM, Mark Rutland wrote: >> Exactly, that is why I was thinking it would take less "review" time. >> Indeed, if there is no driver, why would it matter what those bindings >> are? > > If you believe that the bindings don't matter, then there is absolutely > no reason

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/12/2016 06:56 PM, Mark Rutland wrote: >> Exactly, that's why to I'm having trouble to understand why there is so much >> insistence on "getting the DT 100% right", since a HW change could imply >> that what made 100% sense yesterday, does not today. >> Since that is a possibility

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/12/2016 06:56 PM, Mark Rutland wrote: >> Exactly, that's why to I'm having trouble to understand why there is so much >> insistence on "getting the DT 100% right", since a HW change could imply >> that what made 100% sense yesterday, does not today. >> Since that is a possibility

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Warner, On 09/12/2016 04:26 PM, Warner Losh wrote: > On Mon, Sep 12, 2016 at 8:01 AM, Mark Rutland wrote: >>> Since the question seems understood, do you have an example of other SoC's >>> doing something similar? >> >> I do not have an example. I know that others are

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Warner, On 09/12/2016 04:26 PM, Warner Losh wrote: > On Mon, Sep 12, 2016 at 8:01 AM, Mark Rutland wrote: >>> Since the question seems understood, do you have an example of other SoC's >>> doing something similar? >> >> I do not have an example. I know that others are using DT for data >>

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

On 09/12/2016 06:07 PM, Sebastian Frias wrote: > Hi Mark, > > On 09/12/2016 04:01 PM, Mark Rutland wrote: >>> 3rd parties could choose to write a driver (as opposed to use say, a >>> user-mode >>> library) if it fits their programming model better, if t

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

On 09/12/2016 06:07 PM, Sebastian Frias wrote: > Hi Mark, > > On 09/12/2016 04:01 PM, Mark Rutland wrote: >>> 3rd parties could choose to write a driver (as opposed to use say, a >>> user-mode >>> library) if it fits their programming model better, if t

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/12/2016 04:01 PM, Mark Rutland wrote: >> 3rd parties could choose to write a driver (as opposed to use say, a >> user-mode >> library) if it fits their programming model better, if they think they would >> have better performance, or other reasons. > > A vendor can always choose

Re: ARM, SoC: About the use DT-defined properties by 3rd-party drivers

Hi Mark, On 09/12/2016 04:01 PM, Mark Rutland wrote: >> 3rd parties could choose to write a driver (as opposed to use say, a >> user-mode >> library) if it fits their programming model better, if they think they would >> have better performance, or other reasons. > > A vendor can always choose

  1   2   3   4   >