This allows the battery node in Ingenic SoCs to have a "power-supplies"
property.

Signed-off-by: Paul Cercueil <[email protected]>

Add ingenic,jz4760-battery and ingenic,jz4760b-battery compatible
strings for the JZ4760 and JZ4760B SoCs respectively.

Signed-off-by: Paul Cercueil <[email protected]>

Add the ingenic,jz4760-phy and ingenic,jz4760b-phy compatible strings,
and make the ingenic,jz4770-phy compatible string require
ingenic,jz4760-phy as a fallback, since both work the same, and the
JZ4760 SoC is older.

Signed-off-by: Paul Cercueil <[email protected]>

The JZ4760B is pin-compatible with the JZ4760, but has configurable skew
rate and drive strength that the JZ4760 lacks.

Signed-off-by: Paul Cercueil <[email protected]>

The MIPS CI20 board has a Ingenic IW8103 chip, which is supposedly just
a rebranded Broadcom BCM4330.

Signed-off-by: Paul Cercueil <[email protected]>

Create YAML bindings for the Active-semi PMICs and remove the old text
files.

The bindings aren't perfect, for instance I couldn't find good
descriptions for the vendor properties in the "charger" node of the
ACT8945A because I am not familiar with the hardware and these
properties were not documented anywhere.

The YAML schemas are a bit different than what is described in the old
text files, because these were sometimes wrong or had missing
information. This is the case for the ACT8600 documentation, which
specified the valid node names for the regulators, while the driver was
expecting different names. This led to the current situation where we
have two different boards using different names for the regulators:
- arch/mips/boot/dts/ingenic/ci20.dts uses the names documented in the
  text file,
- arch/mips/boot/dts/ingenic/gcw0.dts uses the names that the driver
  expects.
In theory, the driver should be fixed to follow the documentation, and
accept both naming schemes. In practice though, when the PMIC node was
added to the ci20.dts board file, the names were already wrong in
regards to what the driver expected, so it never really worked
correctly and wasn't tested properly. Furthermore, in that board the
consumers of the regulators aren't working for various other reasons
(invalid GPIOs, etc.).

For that reason, for the ACT8600 bindings I decided to only use the node
names that the driver expects (and that gcw0.dts uses), instead of
accepting both old and new names. A follow-up patch will update the CI20
board to use the new regulator names.

Signed-off-by: Paul Cercueil <[email protected]>

---
v2:
- Avoid | character in descriptions that can be single-line
- Remove unevaluatedProperties when additionalProperties is also present
- Remove useless inner parentheses in regular expressions
- Rename I2C nodes to just... i2c
- Remove node handles

v3:
- Fix alignment in examples
- Drop useless status = "okay"; in examples
- I set myself as the maintainer, which I only did because nobody else
  seems to care.

Cheers,
-Paul

This will make it easier later to introduce support for new chips in
this driver.

Signed-off-by: Paul Cercueil <[email protected]>

Add support for the IT6610 HDMI encoder.

The hardware is very similar, and therefore the driver did not require
too many changes. Some bits are only available on the IT66121, and
vice-versa. Also, the IT6610 requires specific polarities on the DE and
pixel lines.

Signed-off-by: Paul Cercueil <[email protected]>

Add support for the YLM (known as the Anbernic in the western
world) RG-280V, RG-280M, RG-300X, RG-350, RG-350M, and the Wolsen
PocketGo2 (aka. PlayGo) Rev. 1 & 2.

The YLM RG-280V is almost a carbon copy of the GCW-Zero, with a
different LCD panel (320x480 non-square pixels in diamond pattern),
L2/R2 and Vol +/- buttons added, and with the analog stick, ACT8600
regulator, RDA5807 radio, MXC6225 accelerometer, ITE6610 HDMI chips
removed.

The YLM RG-280M v1.1 is a RG-280V with a clickable analog stick. The
v1.0 additionally has a ITE66121 chip.

The Wolsen PocketGo2 Rev. 1 & 2 are similar to the RG-280V, with a
proper 320x240 IPS screen this time.

The RG-350 is a RG-280M v1.0 with two clickable analog sticks, and
a proper 320x240 IPS screen.

The RG-350M is a RG-350 with a 640x480 IPS screen.

The RG-300X is a RG-350 without joysticks.

Signed-off-by: Paul Cercueil <[email protected]>

Add Kconfig symbols and Device Tree files to support the JZ4760 and
JZ4760B SoCs from Ingenic.

Signed-off-by: Paul Cercueil <[email protected]>

The RS-97 from Shenzhen Yangliming Electronic Technology Co., Ltd,
aka YLM, aka Anbernic, is a simple handheld console based around the
JZ4760 SoC.

The RG-300 has the exact same board design, but uses a different LCD
panel and a JZ4760B SoC.

Signed-off-by: Paul Cercueil <[email protected]>

Add support for the QishengLong Gopher 2, which is a handheld that
features the Ingenic JZ4760 SoC.

Also support the QishengLong Gopher 2B, which is the exact same handheld
with some cosmetic changes, and a JZ4760B SoC.

Signed-off-by: Paul Cercueil <[email protected]>

The Wolsen LDK are small handhelds with a 320x480 4:3 TFT LCD screen
(non-square pixels).

Two versions exist, one with a vertical layout (buttons below the
screen) and one with a horizontal layout (buttons on the sides of the
screen). Apart from that difference, the vertical version uses the
JZ4760B SoC, while the horizontal version uses the JZ4760 SoC.

Both are carbon copies of the RS-97 board, except for the different SoC
(for the vertical LDK) and a different panel used.

Signed-off-by: Paul Cercueil <[email protected]>

Signed-off-by: Paul Cercueil <[email protected]>

Signed-off-by: Paul Cercueil <[email protected]>

Make sure that the handheld won't power on, unless the reset pin is
active for 500ms or more.

Signed-off-by: Paul Cercueil <[email protected]>

These flags are useless in this case as the code referencing these data
structures is always seen by the compiler (and not behind #ifdef
guards).

Signed-off-by: Paul Cercueil <[email protected]>

The JZ4750, JZ4755 and JZ4760 (non-B version) support using a 24 MHz
external crystal oscillator instead of the typical 12 MHz one.

However, most of the SoC's IP blocks only work with a 12 MHz clock.
Thanksfully, there is a /2 divider we can enable when a 24 MHz external
crystal is present.

Force-enable this /2 divider when the oscillator is 24 MHz, so that the
SoC always uses a 12 MHz clock internally.

It is done here, and not in the clocks driver, because we need the EXT
clock to be 12 MHz for the early console to work, and the clocks driver
probes way too late.

Signed-off-by: Paul Cercueil <[email protected]>

The RTC module does provide a clock named "osc32k". On the CI20 board,
this clock is supplied to the Bluetooth module and must be enabled for
the Bluetooth and WiFi functionalities to work properly.

Signed-off-by: Paul Cercueil <[email protected]>

The regulators don't have any "reg" property, and therefore shouldn't
use an unit address in their node names.

Signed-off-by: Paul Cercueil <[email protected]>

The reset line is called PWRST#, annotated as "active low" in the
binding documentation, and is driven low and then high by the driver to
reset the chip. However in device tree for CI20 board it was incorrectly
marked as "active high". Fix it.

Because (as far as I know) the ci20.dts is always built in the kernel I
elected not to also add a quirk to gpiolib to force the polarity there.

Fixes: db49ca3 ("net: davicom: dm9000: switch to using gpiod API")
Reported-by: Paul Cercueil <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>

The regulators don't have any "reg" property, and therefore shouldn't
use an unit address in their node names.

Signed-off-by: Paul Cercueil <[email protected]>

No need to specify the GPIO_ACTIVE_LOW flag, it will be ignored.

Signed-off-by: Paul Cercueil <[email protected]>

The Device Tree was using invalid node names for the ACT8600 regulators.
To be fair, it is not the original committer's fault, as the
documentation did gives invalid names as well.

In theory, the fix should have been to modify the driver to accept the
alternative names. However, even though the act8865 driver spits
warnings, the kernel seemed to work fine with what is currently
supported upstream. For that reason, I think it is okay to just update
the DTS.

I removed the "regulator-name" too, since they really didn't bring any
information. The node names are enough.

Fixes: 73f2b94 ("MIPS: CI20: DTS: Add I2C nodes")
Signed-off-by: Paul Cercueil <[email protected]>

Signed-off-by: Paul Cercueil <[email protected]>

…drm', 'for-upstream-dts', 'for-upstream-hdmi', 'for-upstream-iio', 'for-upstream-lto', 'for-upstream-mips', 'for-upstream-mmc', 'for-upstream-panel', 'for-upstream-phy', 'for-upstream-pwm', 'for-upstream-radio', 'for-upstream-remoteproc', 'for-upstream-rtc', 'for-upstream-sound', 'for-upstream-slub' and 'for-upstream-usb' into jz-6.1-base

This frees up a PTE bit so that we can use hugepages.

HACK. NOT FOR UPSTREAM

This reverts commit 69b686d.

Signed-off-by: Paul Cercueil <[email protected]>

This reverts commit 6c9b408.

The patch tries to emulate unaligned access for Ingenic
LXW/LXH/LXHU instructions of MXU subsystem.

The unaligned access is produced by GCC compiler with patches
for adding LX__ instructions but observed only on mips32r2,
mips32r1 seems to be unaffected.

Signed-off-by: Siarhei Volkau <[email protected]>