[PW_SID:1068761] macb usrio/tsu patches#1640
[PW_SID:1068761] macb usrio/tsu patches#1640linux-riscv-bot wants to merge 13 commits intoworkflow__riscv__fixesfrom
Conversation
… platforms have mii mode control in usrio Calling this structure macb_default_usrio is misleading, I believe, as it implies that it should be used if your platform has nothing special to do in usrio. Since usrio is platform dependent, the default here is probably for each usrio to do nothing, with the macb documentation I have access to prescribing no standard behaviour here. We noticed that this was problematic because on mpfs, a bit that macb_default_usrio sets to deal with the MII mode actually changes the source for the tsu_clk to something with how the majority of mpfs devices are actually configured! Rename it to at91_default_usrio, since that's where the values actually come from for these. I have no idea if any of the other platforms that use the default actually copied at91's usrio configuration or if they have usrio configurations where what the driver does has no impact. Gate touching these bits behind a capability, like the clken refclock usrio knob, so that platforms without the MII mode stuff can avoid running this code. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
While trying to rework the internal/external refclk selection on sama7g5, Ryan and I noticed that the sama7g5 was "overloading" the meaning of MACB_CAPS_USRIO_HAS_CLKEN, using it differently to how it was originally intended. Originally, on the macb hardware on sam9620 et al, MACB_CAPS_USRIO_HAS_CLKEN represented the hardware having a bit that needed to be set to turn on the input clock to the transceivers. The sama7g5 doesn't have this bit, so for some reason the decision was made to reuse this capability flag to control selection of internal/external references. Split the caps in two, so that capabilities do what they say on the tin, and allow reworking the refclk selection handling without impacting the older devices that use MACB_CAPS_USRIO_CLKEN for its original purpose. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
…-source Ryan added cdns,refclk-ext with the intent of decoupling the source of the reference clock on sama7g5 (and related platforms) from the compatible. Unfortunately, the default for sama7g5-emac is an external reference clock, so this property had no effect there, so that compatibility with older devicetrees is preserved. Replace cdns,refclk-ext with one that supports both default states and therefore is usable for sama7g5-emac. For now, limit it to only the platforms that have USRIO controlled reference clock selection, but this could be generalised in the future. The existing property only works on devices that are compatible with sama7g5-gem, so mark it deprecated, and limit its use to that specific scenario. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
The USRIO based refclk selection code abuses a capability flag to set the refclk to an external source based on match data/compatible on sama7g5-emac and use an internal source for the gmac. Ryan previously added a property in an attempt to decouple the refclk source from the compatible, because this is not fixed by compatible and there's variance based on the choices made by board designers. Originally when Ryan added it, he removed the capability flag entirely from match data, but this changed the default for the sama7g5-emac and the removal had to be reverted for these devices. Because these devices default to an external refclk, and the current property is only capable of communicating external refclks, there's no way to make the sama7g5-emac use an internal refclk. Additionally, this property has no limiting based on compatible, and if used on a platform with an external refclk that is not controlled by USRIO the capability would be erroneously set. Because of the reuse of the at91_default_usrio struct by non-at91 devices, this could cause the refclk bit to be set in error, on a system where the refclk is externally provided without usrio settings being required. Change the new capability flag so that it actually represents the hardware being capable of controlling the refclk source via USRIO, and move the selection of default behaviour into the macb_usrio_config struct provided as part of match data. Modify the devicetree code to support a new property, "cdns,refclk-source" which will support devices with either default, retaining support for "cdns,refclk-external" for compatibility reasons. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
USRIO is disabled on this platform, having a pointer to a usrio config structure doesn't actually do anything other than look weird. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
On mpfs the driver needs to make sure the tsu clock source is not the fabric, as this requires that the hardware is in Timer Adjust mode, which is not compatible with the linux driver trying to control the hardware. It is unlikely that this will be set, as the peripheral is reset during probe, but if the resets are not provided in devicetree it's probable that this bit is set incorrectly, as U-Boot's macb driver has the same issue with using usrio settings for at91 platforms as the default. Fixes: 8aad66a ("net: macb: add polarfire soc reset support") Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
The Candence GEM IP has a configuration parameter which determines the source of the clock used for the timestamp unit (if it is enabled), switching it between using the pclk and a dedicated input. When ptp support was added to the macb driver, a new tsu_clk was added to represent the dedicated input. While this is understandable, I think it is bug prone and that the tsu_clk should represent whatever clock is used for the timestamper and not just that specific input. >From a driver point of view, the benefit of taking the conceptual approach is avoiding misconfiguring the driver when the hardware supports ptp (and it is set as a capability in the relevant per-device structure) but no tsu_clk is provided in devicetree. At the moment, the timestamper will be registered and programmed with an increment that reflects the pclk in these cases, but will malfunction if the pclk and tsu_clk frequencies do not match. Obviously, this means the devicetree incorrectly represents the hardware, but this change in approach would make the driver more resilient without meaningfully impacting correctly described users. Out of the devices that claim MACB_CAPS_GEM_HAS_PTP the fu540, mpfs, sama5d2 and sama7g5-emac (but not sama7g5-gem) are at risk of having this problem with the in-kernel devicetrees. mpfs and sama7g5-emac have been confirmed to be incorrect, and sama5d2 is correct. It may be that the other platforms actually do use the pclk for the timestamper (either by supplying pclk to the tsu_clk input of the IP, or by having the IP block configured to use pclk instead of the tsu_clk input), but at least two are wrong, as they do not use pclk for the tsu_clk, so the driver is registering the ptp clock incorrectly. Add a warning if no tsu_clk is provided on a platform that uses the timerstamper, to encourage people to specifically provide a tsu_clk and avoid silently registering the timerstamper with the wrong clock. If the pclk is actually used, it can be provided as a tsu_clk for improved clarity in devicetrees. While this changes the meaning of the devicetree property, it is backwards compatible as there's no functional change for platforms that didn't provide a tsu_clk and the changed meaning of providing a tsu_clk in the devicetree does not impact platforms that already provided one as the decision about the tsu clock source is at IP instantiation time rather than at runtime, so there's no driver behaviour that needs to change based on the input to the IP used for the timestamping unit. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
tsu_clk is grabbed during probe, so doesn't need to be re-grabbed here. pclk is mandatory, probe will fail if it is err/NULL, so there's no need to check it here or have a !pclk 3rd arm. Simplify gem_get_tsu_rate() to account for these facts. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
The GEM IP has two methods for modifying the ptp timer. The first of these, named "increment mode", relies on software controlling the timer by setting tsu_timer_incr and tsu_timer_incr_sub_nsec and performing once-off adjustments via the tsu_timer_adjust register. This is what the macb driver uses. The second mechanism, "timer adjust mode" uses the gem_tsu_inc_ctrl and gem_tsu_ms signals to control the timer. These modes are not intended to be used in parallel, but both can be possible on the same device and which mode is used cannot be determined from the compatible on all devices, because some users of the GEM IP are SoC FPGAs that permit configuring how the IP is wired up. Add a property to indicate that gem_tsu_inc_ctrl and gem_tsu_ms are wired up for timer adjust mode. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
The ptp portion of this driver controls the tsu's timer using the controls for "increment mode", which is not compatible with the hardware trying to control it via the gem_tsu_inc_ctrl and gem_tsu_ms inputs in "timer adjust mode". Abort probe if the property signalling that the relevant signals have been wired up is present. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
DCFG1 (design config 1 register) carries a bit indicating whether User I/O feature has been enabled or not. The MACB/GEM driver has a cap flag indicating that HW has the feature disabled (default is enabled). Add the missing connection between DCFG1 bit and MACB_CAPS_USRIO_DISABLED. Indirect impact: avoid useless writel() on USERIO register; this is not an important fix because USERIO is anyway read-only when feature is disabled. If for some reason a compatible sets USRIO_DISABLED but DCFG1 indicates it is enabled, we still keep the disabled capability flag. This ensures we don't break "cdns,np4-macb" that sets the flag from compatible match data. Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
bp->usrio is copied directly from dt_conf->usrio in macb_probe(). If dt_conf->usrio is NULL, we do not want to land in USRIO write codepaths which dereference bp->usrio. Inherit automatically MACB_CAPS_USRIO_DISABLED to avoid those. This means a macb_config that wants to disable usrio can simply drop its .usrio field, rather than add the disabled capability explicitly. Nit: drop the dt_conf NULL check because the pointer is always valid. Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
USRIO is disabled on this platform, drop its inherited usrio config. We will end up with MACB_CAPS_USRIO_DISABLED on this platform: - We have no config->usrio so macb_configure_caps() deduces that the feature is disabled. - Anecdotally, we would also land in the runtime detection codepath that reads DCFG1. Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
|
Patch 1: "[net-next,v4,01/13] net: macb: rename macb_default_usrio to at91_default_usrio as not all platforms have mii mode control in usrio" |
|
Patch 1: "[net-next,v4,01/13] net: macb: rename macb_default_usrio to at91_default_usrio as not all platforms have mii mode control in usrio" |
|
Patch 1: "[net-next,v4,01/13] net: macb: rename macb_default_usrio to at91_default_usrio as not all platforms have mii mode control in usrio" |
|
Patch 1: "[net-next,v4,01/13] net: macb: rename macb_default_usrio to at91_default_usrio as not all platforms have mii mode control in usrio" |
|
Patch 1: "[net-next,v4,01/13] net: macb: rename macb_default_usrio to at91_default_usrio as not all platforms have mii mode control in usrio" |
|
Patch 1: "[net-next,v4,01/13] net: macb: rename macb_default_usrio to at91_default_usrio as not all platforms have mii mode control in usrio" |
|
Patch 1: "[net-next,v4,01/13] net: macb: rename macb_default_usrio to at91_default_usrio as not all platforms have mii mode control in usrio" |
|
Patch 1: "[net-next,v4,01/13] net: macb: rename macb_default_usrio to at91_default_usrio as not all platforms have mii mode control in usrio" |
|
Patch 1: "[net-next,v4,01/13] net: macb: rename macb_default_usrio to at91_default_usrio as not all platforms have mii mode control in usrio" |
|
Patch 1: "[net-next,v4,01/13] net: macb: rename macb_default_usrio to at91_default_usrio as not all platforms have mii mode control in usrio" |
|
Patch 1: "[net-next,v4,01/13] net: macb: rename macb_default_usrio to at91_default_usrio as not all platforms have mii mode control in usrio" |
|
Patch 1: "[net-next,v4,01/13] net: macb: rename macb_default_usrio to at91_default_usrio as not all platforms have mii mode control in usrio" |
|
Patch 2: "[net-next,v4,02/13] net: macb: split USRIO_HAS_CLKEN capability in two" |
|
Patch 2: "[net-next,v4,02/13] net: macb: split USRIO_HAS_CLKEN capability in two" |
|
Patch 2: "[net-next,v4,02/13] net: macb: split USRIO_HAS_CLKEN capability in two" |
|
Patch 2: "[net-next,v4,02/13] net: macb: split USRIO_HAS_CLKEN capability in two" |
|
Patch 2: "[net-next,v4,02/13] net: macb: split USRIO_HAS_CLKEN capability in two" |
|
Patch 11: "[net-next,v4,11/13] net: macb: runtime detect MACB_CAPS_USRIO_DISABLED" |
|
Patch 11: "[net-next,v4,11/13] net: macb: runtime detect MACB_CAPS_USRIO_DISABLED" |
|
Patch 11: "[net-next,v4,11/13] net: macb: runtime detect MACB_CAPS_USRIO_DISABLED" |
|
Patch 11: "[net-next,v4,11/13] net: macb: runtime detect MACB_CAPS_USRIO_DISABLED" |
|
Patch 11: "[net-next,v4,11/13] net: macb: runtime detect MACB_CAPS_USRIO_DISABLED" |
|
Patch 11: "[net-next,v4,11/13] net: macb: runtime detect MACB_CAPS_USRIO_DISABLED" |
|
Patch 12: "[net-next,v4,12/13] net: macb: set MACB_CAPS_USRIO_DISABLED if no usrio config is provided" |
|
Patch 12: "[net-next,v4,12/13] net: macb: set MACB_CAPS_USRIO_DISABLED if no usrio config is provided" |
|
Patch 12: "[net-next,v4,12/13] net: macb: set MACB_CAPS_USRIO_DISABLED if no usrio config is provided" |
|
Patch 12: "[net-next,v4,12/13] net: macb: set MACB_CAPS_USRIO_DISABLED if no usrio config is provided" |
|
Patch 12: "[net-next,v4,12/13] net: macb: set MACB_CAPS_USRIO_DISABLED if no usrio config is provided" |
|
Patch 12: "[net-next,v4,12/13] net: macb: set MACB_CAPS_USRIO_DISABLED if no usrio config is provided" |
|
Patch 12: "[net-next,v4,12/13] net: macb: set MACB_CAPS_USRIO_DISABLED if no usrio config is provided" |
|
Patch 12: "[net-next,v4,12/13] net: macb: set MACB_CAPS_USRIO_DISABLED if no usrio config is provided" |
|
Patch 12: "[net-next,v4,12/13] net: macb: set MACB_CAPS_USRIO_DISABLED if no usrio config is provided" |
|
Patch 12: "[net-next,v4,12/13] net: macb: set MACB_CAPS_USRIO_DISABLED if no usrio config is provided" |
|
Patch 12: "[net-next,v4,12/13] net: macb: set MACB_CAPS_USRIO_DISABLED if no usrio config is provided" |
|
Patch 12: "[net-next,v4,12/13] net: macb: set MACB_CAPS_USRIO_DISABLED if no usrio config is provided" |
|
Patch 13: "[net-next,v4,13/13] net: macb: drop usrio pointer on EyeQ5 config" |
|
Patch 13: "[net-next,v4,13/13] net: macb: drop usrio pointer on EyeQ5 config" |
|
Patch 13: "[net-next,v4,13/13] net: macb: drop usrio pointer on EyeQ5 config" |
|
Patch 13: "[net-next,v4,13/13] net: macb: drop usrio pointer on EyeQ5 config" |
|
Patch 13: "[net-next,v4,13/13] net: macb: drop usrio pointer on EyeQ5 config" |
|
Patch 13: "[net-next,v4,13/13] net: macb: drop usrio pointer on EyeQ5 config" |
|
Patch 13: "[net-next,v4,13/13] net: macb: drop usrio pointer on EyeQ5 config" |
|
Patch 13: "[net-next,v4,13/13] net: macb: drop usrio pointer on EyeQ5 config" |
|
Patch 13: "[net-next,v4,13/13] net: macb: drop usrio pointer on EyeQ5 config" |
|
Patch 13: "[net-next,v4,13/13] net: macb: drop usrio pointer on EyeQ5 config" |
|
Patch 13: "[net-next,v4,13/13] net: macb: drop usrio pointer on EyeQ5 config" |
|
Patch 13: "[net-next,v4,13/13] net: macb: drop usrio pointer on EyeQ5 config" |
3 participants
PR for series 1068761 applied to workflow__riscv__fixes
Name: macb usrio/tsu patches
URL: https://patchwork.kernel.org/project/linux-riscv/list/?series=1068761
Version: 4