[linux-sunxi] [PATCH v4 2/2] ARM: dts: sun4i: Add support for Topwise A721 tablet

2021-02-22 Thread Pascal Roeleven
The Topwise A721/LY-F1 tablet is a tablet sold around 2012 under
different brands. The mainboard mentions A721 clearly, so this tablet
is best known under this name.

Signed-off-by: Pascal Roeleven 
---
 arch/arm/boot/dts/Makefile   |   3 +-
 arch/arm/boot/dts/sun4i-a10-topwise-a721.dts | 242 +++
 2 files changed, 244 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/sun4i-a10-topwise-a721.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 3d1ea0b251..ba25b4235a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1103,7 +1103,8 @@ dtb-$(CONFIG_MACH_SUN4I) += \
sun4i-a10-olinuxino-lime.dtb \
sun4i-a10-pcduino.dtb \
sun4i-a10-pcduino2.dtb \
-   sun4i-a10-pov-protab2-ips9.dtb
+   sun4i-a10-pov-protab2-ips9.dtb \
+   sun4i-a10-topwise-a721.dtb
 dtb-$(CONFIG_MACH_SUN5I) += \
sun5i-a10s-auxtek-t003.dtb \
sun5i-a10s-auxtek-t004.dtb \
diff --git a/arch/arm/boot/dts/sun4i-a10-topwise-a721.dts 
b/arch/arm/boot/dts/sun4i-a10-topwise-a721.dts
new file mode 100644
index 00..2c417c408b
--- /dev/null
+++ b/arch/arm/boot/dts/sun4i-a10-topwise-a721.dts
@@ -0,0 +1,242 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020 Pascal Roeleven 
+ */
+
+/dts-v1/;
+#include "sun4i-a10.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   model = "Topwise A721";
+   compatible = "topwise,a721", "allwinner,sun4i-a10";
+
+   aliases {
+   serial0 = 
+   };
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = < 0 10 PWM_POLARITY_INVERTED>;
+   power-supply = <_vbat>;
+   enable-gpios = < 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
+   brightness-levels = <0 30 40 50 60 70 80 90 100>;
+   default-brightness-level = <8>;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   panel {
+   compatible = "starry,kr070pe2t";
+   backlight = <>;
+   power-supply = <_lcd_power>;
+
+   port {
+   panel_input: endpoint {
+   remote-endpoint = <_out_panel>;
+   };
+   };
+   };
+
+   reg_lcd_power: reg-lcd-power {
+   compatible = "regulator-fixed";
+   regulator-name = "reg-lcd-power";
+   gpio = < 7 8 GPIO_ACTIVE_HIGH>; /* PH8 */
+   enable-active-high;
+   };
+
+   reg_vbat: reg-vbat {
+   compatible = "regulator-fixed";
+   regulator-name = "vbat";
+   regulator-min-microvolt = <370>;
+   regulator-max-microvolt = <370>;
+   };
+
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   cpu-supply = <_dcdc2>;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   axp209: pmic@34 {
+   reg = <0x34>;
+   interrupts = <0>;
+   };
+};
+
+#include "axp209.dtsi"
+
+_power_supply {
+   status = "okay";
+};
+
+_power_supply {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   accelerometer@4c {
+   compatible = "fsl,mma7660";
+   reg = <0x4c>;
+   };
+};
+
+ {
+   status = "okay";
+
+   touchscreen@38 {
+   compatible = "edt,edt-ft5406";
+   reg = <0x38>;
+   interrupt-parent = <>;
+   interrupts = <7 21 IRQ_TYPE_EDGE_FALLING>;
+   touchscreen-size-x = <800>;
+   touchscreen-size-y = <480>;
+   vcc-supply = <_vcc3v3>;
+   };
+};
+
+ {
+   vref-supply = <_ldo2>;
+   status = "okay";
+
+   button-761 {
+   label = "Volume Down";
+   linux,code = ;
+   channel = <0>;
+   voltage = <761904>;
+   };
+
+   button-571 {
+   label = "Volume Up";
+   linux,code = ;
+   channel = <0>;
+   voltage = <571428>;
+   };
+};
+
+ {
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <4>;
+   cd-gpios = < 7 1 GPIO_ACTIVE_LOW>; /* PH01 */
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_sram {
+   status = "okay";
+};
+
+ {
+   vcc-pb-supply = <_vcc3v3>;
+   vcc-pf-supply = <_vcc3v3>;
+   vcc-ph-supply = <_vcc3v3>;
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pin>;
+   status = "okay";
+};
+
+_dcdc2 {
+   regulator-always-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-cpu";
+};
+
+_dcdc3 {
+   regulator-always-on;
+   regulator-min-microvolt = <125>;
+   

[linux-sunxi] [PATCH v4 1/2] dt-bindings: arm: Add Topwise A721

2021-02-22 Thread Pascal Roeleven
Add the bindings for Topwise A721 tablet

Signed-off-by: Pascal Roeleven 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml 
b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 6db32fbf81..8833a9c925 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -787,6 +787,11 @@ properties:
   - const: tbs-biometrics,a711
   - const: allwinner,sun8i-a83t
 
+  - description: Topwise A721 Tablet
+items:
+  - const: topwise,a721
+  - const: allwinner,sun4i-a10
+
   - description: Utoo P66
 items:
   - const: utoo,p66
-- 
2.27.0


-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210222100826.12478-2-dev%40pascalroeleven.nl.


[linux-sunxi] [PATCH v4 0/2] Add support for Topwise A721 tablet

2021-02-22 Thread Pascal Roeleven
On request I'm resending the last two patches from the Topwise A721 tablet
series from a year ago as they weren't picked up. The other patches are
already merged, so I didn't resend them.

Changes from v3:
* Fix DT validation warnings
* Remove leftover labels

Changes from v2:
* Collected acked-by.

Original cover letter:

This series add support for the Topwise A721 tablet and it's display.
It is an old tablet (around 2012) but it might be useful as reference
as the devicetree is pretty complete.

Changes from v1:
* Split into multiple patches
* dt-binding: use yaml instead of txt
* dt-binding: add Topwise A721 to sunxi.yaml
* dt-binding: add Topwise to vendor-prefixes
* drm: Add bus_format, bus_flags and connector_type
* dts: Use SPDX license identifier instead of boilerplate license text
* dts: Remove pinctrl leftovers

Pascal Roeleven (2):
  dt-bindings: arm: Add Topwise A721
  ARM: dts: sun4i: Add support for Topwise A721 tablet

 .../devicetree/bindings/arm/sunxi.yaml|   5 +
 arch/arm/boot/dts/Makefile|   3 +-
 arch/arm/boot/dts/sun4i-a10-topwise-a721.dts  | 242 ++
 3 files changed, 249 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/sun4i-a10-topwise-a721.dts

-- 
2.27.0


-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210222100826.12478-1-dev%40pascalroeleven.nl.


[linux-sunxi] Re: [PATCH v3] video: sunxi_display: Convert to DM_VIDEO

2021-02-22 Thread Maxime Ripard
On Sun, Feb 21, 2021 at 09:24:18AM -0700, Simon Glass wrote:
> > > > +static int sunxi_de_bind(struct udevice *dev)
> > > > +{
> > > > +   struct video_uc_plat *plat = dev_get_uclass_plat(dev);
> > > > +
> > > > +   plat->size = LCD_MAX_WIDTH * LCD_MAX_HEIGHT *
> > > > +(1 << LCD_MAX_LOG2_BPP) / 8;
> > >
> > > Should use enum video_log2_bpp here. Also see VNBYTES().
> >
> > LCD_MAX_LOG2_BPP is defined as VIDEO_BPP32 at the very top. Sure will
> > use VNBYTES.
> >
> > On a related topic: IIUC this is called several times, for a start once
> > before relocation, where it's supposed to give an upper bound?
> > Are subsequent calls then expected to be more precise? Our 32MB frame
> > buffer is *very* generous, for the usual FullHD display we just need
> > 8MB. But we would only know this in probe(), when we have learned the
> > output device and the video modes it supports.
> > So is there a way to restrict (and possibly also move) the framebuffer
> > in probe()?
> 
> I suppose you can, but that is not what is expected. You don't save
> memory for U-Boot (and it doesn't matter), but making it smaller so
> that linux uses less would be worthwhile. We just need to make sure
> this is documented in video.h and tested.
> 
> To be clear, you have my review thg, so these are things that can be done 
> later.

Seems Andre seems to be motivated to rework that driver, I guess we
could also rework how this is done.

Ideally, we should be describing the reserved buffer through a
reserved-memory node in the DT instead of carving out some memory for
Linux. That way, if we don't have simplefb support, or it's replaced by
something else eventually, we have a chance a claiming that memory back
at some point, instead of just ignoring it.

Maxime

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210222090223.4uvwdlcyq3lpcyb4%40gilmour.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v3] video: sunxi_display: Convert to DM_VIDEO

2021-02-22 Thread Maxime Ripard
Hi Andre,

On Sun, Feb 21, 2021 at 12:07:35AM +, Andre Przywara wrote:
> > >  enum sunxi_monitor {
> > > sunxi_monitor_none,
> > > sunxi_monitor_dvi,
> > > @@ -59,12 +68,11 @@ enum sunxi_monitor {
> > >  #define SUNXI_MONITOR_LAST sunxi_monitor_composite_pal_nc
> > >
> > >  struct sunxi_display {
> > > -   GraphicDevice graphic_device;
> > > enum sunxi_monitor monitor;
> > > unsigned int depth;
> > > unsigned int fb_addr;
> > > unsigned int fb_size;  
> > 
> > These last three are repeated from the uclass info. But fb_addr seems
> > to sometimes be different from the ucass frame buffer, in which case I
> > wonder how output actually works.
> > 
> > If you do actually need these, can you please document them here?
> 
> I think this might be mostly non-DM legacy, but for the composite
> overscan we tweak the framebuffer address. I haven't fully wrapped
> my mind around this, though, and ideally we can indeed lose those
> extra members.
> I will try to find some device with composite input to test it.

So the overscan will put the edges of any displayed image out of the
visible area of the screen, right? The amount of content non-visible due
to this isn't really standard and any display will behave differently
there.

One way to deal with this is to rescale the composited image to a
slightly smaller and center it in the middle of the screen.

We don't have that option though, so the code will instead render in a
slightly smaller resolution, centered in the framebuffer.

Note that composite isn't the only output that you can test this on:
HDMI TVs will also use overscan.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20210222085950.odtmixec52rud5qw%40gilmour.


signature.asc
Description: PGP signature