[OpenWrt-Devel] [PATCH] ramips: add support for ASUS RT-AC57U

[Christian Lamparter]

Hi David,

On Monday, June 24, 2019 10:00:06 PM CEST David Bauer wrote:
> Hello Christian,
> >> +
> >> +	keys {
> >> +		compatible = "gpio-keys-polled";
> > The MT7261 should support interrupt-supported gpio-keys.
> 
> I will try your suggestion, however i suspect we will face the same 
> issues we have on the ath79 platform currently.

Well, from what I can tell the gpio in the apm821xx works differently
than that of the ath79... and the mt7621 will be different as well.

I wonder if making the change brought just enough attention to the
driver and everyone just checked and found some hidden issues.
 
> While we are at it - i haven't forgotten about this one but due to 
> hardware issues, testing is currently a bit cumbersome.

No sweat :) (Yes, it's already too hot). 
 
> > 
> >> +		poll-interval = <20>;
> >> +
> >> +		wps {
> >> +			label = "wps";
> >> +			gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
> >> +			linux,code = <KEY_WPS_BUTTON>;
> >> +		};
> >> +
> >> +		reset {
> >> +			label = "reset";
> >> +			gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
> >> +			linux,code = <KEY_RESTART>;
> >> +		};
> >> +	};
> >> +
> >> +	led-regulator {
> >> +		compatible = "regulator-fixed";
> >> +		regulator-name = "LED-Power";
> >> +		gpio = <&gpio1 14 GPIO_ACTIVE_LOW>;
> >> +		regulator-min-microvolt = <3300000>;
> >> +		regulator-max-microvolt = <3300000>;
> >> +		regulator-always-on;
> > Just curious, is this regulator related to ASUS "Night mode"
> > feature? Also did you measure the voltages or is there a
> > 3v3 LED driver on the board?
> 
> I suppose it is as the PHY LEDs seem to be controlled in hardware and so 
> can't be toggled from software. The voltage is the one that goes to the 
> LEDs.
> 
> Thinking about this, do you think we are better off using a "fake" LED 
> for this that we set default on? A user is then able to turn off even 
> the LEDs we can't control in software. We could name it something like 
> "rt-ac57u:power:led". However, this would violate the naming scheme.
> 
> What do you think?

I think we should extend LuCI & friends so it can switch on/off these
regulators ;). (Note: we probably don't want to mess with all regulators
, usb-regulators for example should be controlled by the driver).
> >> +	};
> >> +};
> >> +
> >> +&spi0 {
> >> +	status = "okay";
> >> +
> >> +	flash at 0 {
> >> +		compatible = "jedec,spi-nor";
> >> +		reg = <0>;
> >> +		spi-max-frequency = <10000000>;
> > I haven't said much about the spi-max-frequencies before
> > but from what I know thanks to the threads like
> > "ramips: Increase GB-PC1 SPI frequency to 80MHz" the original
> > these values are off. And once the target switches to 4.19 (and
> > uses the upstream mt7621a.dtsi + spi-driver) this needs to be
> > reworked on all devices I think
> 
> I just head a quick look over this thread and the driver. I might be 
> missing something, but shouldn't the spi bus run with 10 MHz in this case?

Is 10MHz even a supported frequency for the SPI-NOR chip? From what I know
the problem arose because of the dodgy 50MHz value for the sysclock for the
MT7621 (I think it's 200 MHz so it's 4 times as fast).

If you look into the mt7621 datasheet you see that the SPI frequency is
generated from the sysclock and the driver just sets the divisor. So the
"10 MHz" spi frequency would actually be "40" MHz".

I think you can measure the time it takes to read the SPI-NOR and check
if the KiB/s match with the selected frequency or not.

(That said, this is wrong on so many other ramips. so.)

Cheers,
Christian



_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel