@@ -0,0 +1,7 @@+CDTech(H.K.) Electronics Limited 4.3" 480x272 color TFT-LCD panel++Required properties:+- compatible: should be "cdtech,s043wq26h-ct7"++This binding is compatible with the simple-panel binding, which is specified+in simple-panel.txt in this directory.
@@ -0,0 +1,7 @@+CDTech(H.K.) Electronics Limited 4.3" 480x272 color TFT-LCD panel++Required properties:+- compatible: should be "cdtech,s043wq26h-ct7"++This binding is compatible with the simple-panel binding, which is specified+in simple-panel.txt in this directory.
Same comment here.
Also, please split bindings to separate patches.
Rob
The A20-Linova1-7 HMI, also called Q027_2_F which is printed on production
label, is an industrial Human Machine Interface.
It features:
- 512MB DDR RAM
- 1 Sd-card >= 4GB
- 1 Usb otg(programmable via software) with A-Usb Connector
- 1 Usb host
- 1 Buzzer
- 1 Input for LiPo
- 1 Relay to signal absence of power supply
- 1 External Rtc with 56 bytes of ram + CR2032 battery
- 1 7" 24-bits Tft 800x480 with PCap on
- 1 Mono audio 1-watt amplifier
- 1 RS485 port
- 1 Power On Line through +12Vdc reaching 57.600baud,
from where it can be supplied and placed in a network of 50 units
- exposed jtag pins
HMI is supplied from +12Vdc.
Ethernet is absent, so for debugging, need to enable rndis on Usb otg
port through an A-A usb cable.
It comes in different flavours for connector types and can be found with
umounted features as requested by customers.
Signed-off-by: Giulio Benetti <redacted>
---
.../devicetree/bindings/arm/micronova.txt | 4 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts | 192 +++++++++++++++++++++
3 files changed, 197 insertions(+)
create mode 100644 arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts
From: Maxime Ripard <hidden> Date: 2018-03-22 18:05:13
On Wed, Mar 21, 2018 at 09:03:13PM +0100, Giulio Benetti wrote:
The A20-Linova1-7 HMI, also called Q027_2_F which is printed on production
label, is an industrial Human Machine Interface.
It features:
- 512MB DDR RAM
- 1 Sd-card >= 4GB
- 1 Usb otg(programmable via software) with A-Usb Connector
- 1 Usb host
- 1 Buzzer
- 1 Input for LiPo
- 1 Relay to signal absence of power supply
- 1 External Rtc with 56 bytes of ram + CR2032 battery
- 1 7" 24-bits Tft 800x480 with PCap on
- 1 Mono audio 1-watt amplifier
- 1 RS485 port
- 1 Power On Line through +12Vdc reaching 57.600baud,
from where it can be supplied and placed in a network of 50 units
- exposed jtag pins
HMI is supplied from +12Vdc.
Ethernet is absent, so for debugging, need to enable rndis on Usb otg
port through an A-A usb cable.
It comes in different flavours for connector types and can be found with
umounted features as requested by customers.
So this is essentially the same board than in patch 6, but with a
different screen?
You should have a single DT then, and handle the two different panels
using DT overlays.
The nodes should be ordered by alphabetical order.
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
Hi,
Il 22/03/2018 19:05, Maxime Ripard ha scritto:
On Wed, Mar 21, 2018 at 09:03:13PM +0100, Giulio Benetti wrote:
quoted
The A20-Linova1-7 HMI, also called Q027_2_F which is printed on production
label, is an industrial Human Machine Interface.
It features:
- 512MB DDR RAM
- 1 Sd-card >= 4GB
- 1 Usb otg(programmable via software) with A-Usb Connector
- 1 Usb host
- 1 Buzzer
- 1 Input for LiPo
- 1 Relay to signal absence of power supply
- 1 External Rtc with 56 bytes of ram + CR2032 battery
- 1 7" 24-bits Tft 800x480 with PCap on
- 1 Mono audio 1-watt amplifier
- 1 RS485 port
- 1 Power On Line through +12Vdc reaching 57.600baud,
from where it can be supplied and placed in a network of 50 units
- exposed jtag pins
HMI is supplied from +12Vdc.
Ethernet is absent, so for debugging, need to enable rndis on Usb otg
port through an A-A usb cable.
It comes in different flavours for connector types and can be found with
umounted features as requested by customers.
So this is essentially the same board than in patch 6, but with a
different screen?
You should have a single DT then, and handle the two different panels
using DT overlays.
Ok for having different DT overlays.
But do I have to submit them as patches? Or keep them in my company's repo?
I ask you this because this involves sending also patches for displays
and other little modifications to mainline ex:
- rgb888 pins
- 2 simple-panels
- 1 uart iomux pins
etc.
If I don't submit those overlays, the other patches wouldn't make sense
alone as I've seen, just like rgb888 pins.
The nodes should be ordered by alphabetical order.
Done.
One last question:
now I have some patch already reviewed-by.
Do I have to re-submit entire patchset?
Thank you very much.
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
From: Maxime Ripard <hidden> Date: 2018-04-24 08:42:11
Hi,
On Mon, Apr 23, 2018 at 04:37:33PM +0200, Giulio Benetti wrote:
Il 22/03/2018 19:05, Maxime Ripard ha scritto:
quoted
On Wed, Mar 21, 2018 at 09:03:13PM +0100, Giulio Benetti wrote:
quoted
The A20-Linova1-7 HMI, also called Q027_2_F which is printed on production
label, is an industrial Human Machine Interface.
It features:
- 512MB DDR RAM
- 1 Sd-card >= 4GB
- 1 Usb otg(programmable via software) with A-Usb Connector
- 1 Usb host
- 1 Buzzer
- 1 Input for LiPo
- 1 Relay to signal absence of power supply
- 1 External Rtc with 56 bytes of ram + CR2032 battery
- 1 7" 24-bits Tft 800x480 with PCap on
- 1 Mono audio 1-watt amplifier
- 1 RS485 port
- 1 Power On Line through +12Vdc reaching 57.600baud,
from where it can be supplied and placed in a network of 50 units
- exposed jtag pins
HMI is supplied from +12Vdc.
Ethernet is absent, so for debugging, need to enable rndis on Usb otg
port through an A-A usb cable.
It comes in different flavours for connector types and can be found with
umounted features as requested by customers.
So this is essentially the same board than in patch 6, but with a
different screen?
You should have a single DT then, and handle the two different panels
using DT overlays.
Ok for having different DT overlays.
But do I have to submit them as patches? Or keep them in my company's repo?
I ask you this because this involves sending also patches for displays
and other little modifications to mainline ex:
- rgb888 pins
- 2 simple-panels
- 1 uart iomux pins
etc.
If I don't submit those overlays, the other patches wouldn't make sense
alone as I've seen, just like rgb888 pins.
We don't have a repo for overlays yet
quoted
quoted
+&usb_otg {
+ dr_mode = "otg";
You're saying that this is a USB-A connector? Then it's not OTG since
it doesn't have an ID pin, this is an host.
Right, with a special overlay I will activate Usb Device for RNDIS,
so modified as host
That doesn't really make much sense. The USB OTG is wired only using a
daughter board?
One last question:
now I have some patch already reviewed-by.
Do I have to re-submit entire patchset?
Yes
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
Hi Maxime and all,
I resend the e-mail since it was refused by some address(my phone
composed it in HTML). Sorry.
Il 24/04/2018 10:41, Maxime Ripard ha scritto:
Hi,
On Mon, Apr 23, 2018 at 04:37:33PM +0200, Giulio Benetti wrote:
quoted
Il 22/03/2018 19:05, Maxime Ripard ha scritto:
quoted
On Wed, Mar 21, 2018 at 09:03:13PM +0100, Giulio Benetti wrote:
quoted
The A20-Linova1-7 HMI, also called Q027_2_F which is printed on production
label, is an industrial Human Machine Interface.
It features:
- 512MB DDR RAM
- 1 Sd-card >= 4GB
- 1 Usb otg(programmable via software) with A-Usb Connector
- 1 Usb host
- 1 Buzzer
- 1 Input for LiPo
- 1 Relay to signal absence of power supply
- 1 External Rtc with 56 bytes of ram + CR2032 battery
- 1 7" 24-bits Tft 800x480 with PCap on
- 1 Mono audio 1-watt amplifier
- 1 RS485 port
- 1 Power On Line through +12Vdc reaching 57.600baud,
from where it can be supplied and placed in a network of 50 units
- exposed jtag pins
HMI is supplied from +12Vdc.
Ethernet is absent, so for debugging, need to enable rndis on Usb otg
port through an A-A usb cable.
It comes in different flavours for connector types and can be found with
umounted features as requested by customers.
So this is essentially the same board than in patch 6, but with a
different screen?
You should have a single DT then, and handle the two different panels
using DT overlays.
Ok for having different DT overlays.
But do I have to submit them as patches? Or keep them in my company's repo?
I ask you this because this involves sending also patches for displays
and other little modifications to mainline ex:
- rgb888 pins
- 2 simple-panels
- 1 uart iomux pins
etc.
If I don't submit those overlays, the other patches wouldn't make sense
alone as I've seen, just like rgb888 pins.
We don't have a repo for overlays yet
Ok I can provide them on my company Repo.
But, sorry if insist(please don't kill me! :) ), I would try to explain
better how it's made LiNova, because I think I didn't provide enough
information about it:
LiNova1 is not a board with various headers to connect other peripherals
such display, pcap etc.
It's an HMI that I would consider the same as a Tablet, because it has a
plastic enclosure also.
So I would like to understand how to manage it in the best way.
Try to consider LiNova1 as a Tablet series, with following list:
LiNova1 4.3" ctp
LiNova1 7" ctp
LiNova1 10.1" ctp
LiNova1 4.3" rtp
LiNova1 7" rtp
LiNova1 10.1" rtp
Every of those has a slightly different BOM, so they are 6 different
boards with a common base(uP, ram). And same pcb.
So I don't know if submit only the common base and provide separately on
our github DT-overlays, or provide as many dts patches as the HMI number
with a base dtsi.
Basically Micronova provides entire system without the capability to
hack hardware adding shields of various type.
There are also other 2 LiNova:
LiNova2 and LiNova3
So I understand that this could lead to 18 different dts files and 3
dtsi files.
But with Tablet it should be the same way.
For sure people would be more interested on famous tablets instead of
our HMI.
In the case I need to use dt-overlays, you mean .dto files with
fragments inside loaded by u-boot or runtime, right?
Sorry if I bother you again but I wanted to understand better.
quoted
quoted
quoted
+&usb_otg {
+ dr_mode = "otg";
You're saying that this is a USB-A connector? Then it's not OTG since
it doesn't have an ID pin, this is an host.
Right, with a special overlay I will activate Usb Device for RNDIS,
so modified as host
That doesn't really make much sense. The USB OTG is wired only using a
daughter board?
My fault, I've meant "peripheral" in one case and "host" in another case.
Usually "host".
Are there problem with this?
There is no daughter board.
Thank you very very much in advance for you patience :)
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
quoted
One last question:
now I have some patch already reviewed-by.
Do I have to re-submit entire patchset?
From: Maxime Ripard <hidden> Date: 2018-04-25 18:40:32
Hi Giulio,
On Tue, Apr 24, 2018 at 08:31:44PM +0200, Giulio Benetti wrote:
LiNova1 is not a board with various headers to connect other peripherals
such display, pcap etc.
It's an HMI that I would consider the same as a Tablet, because it has a
plastic enclosure also.
So I would like to understand how to manage it in the best way.
Try to consider LiNova1 as a Tablet series, with following list:
LiNova1 4.3" ctp
LiNova1 7" ctp
LiNova1 10.1" ctp
LiNova1 4.3" rtp
LiNova1 7" rtp
LiNova1 10.1" rtp
Every of those has a slightly different BOM, so they are 6 different
boards with a common base(uP, ram). And same pcb.
So the LiNova1 is exactly the same in all these setups, the only
difference is that it has a connector that you connect a different
display / touchscreen to?
If so, that's definitely a case for device tree overlays.
So I don't know if submit only the common base and provide
separately on our github DT-overlays, or provide as many dts patches
as the HMI number with a base dtsi.
That's really up to you, but the overlays will make this much simpler
to handle precisely because it will reduce the amount of combinations
you have.
You can even reduce it in your case to 5 of them, 3 for each panel and
2 for each touchscreen.
Basically Micronova provides entire system without the capability to hack
hardware adding shields of various type.
There are also other 2 LiNova:
LiNova2 and LiNova3
Which SoCs are these boards based on?
So I understand that this could lead to 18 different dts files and 3
dtsi files.
Yeah, I'd really like to keep this under control :)
But with Tablet it should be the same way. For sure people would be
more interested on famous tablets instead of our HMI.
In the case I need to use dt-overlays, you mean .dto files with
fragments inside loaded by u-boot or runtime, right?
You don't have to handcode the fragments anymore with the new syntax,
and U-Boot makes it really trivial to use if you use the FIT image
format to have multiple overlays bundled in the same image. You can
choose to apply them dynamically, for example based on an EEPROM or
some other metric to see which combination you have.
quoted
quoted
quoted
quoted
+&usb_otg {
+ dr_mode = "otg";
You're saying that this is a USB-A connector? Then it's not OTG since
it doesn't have an ID pin, this is an host.
Right, with a special overlay I will activate Usb Device for RNDIS,
so modified as host
That doesn't really make much sense. The USB OTG is wired only using a
daughter board?
My fault, I've meant "peripheral" in one case and "host" in another case.
Usually "host".
Are there problem with this?
There is no daughter board.
If you have an ID pin and the ability to control VBUS, then you don't
need to change the device tree, it's done automatically at runtime by
Linux.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Maxime,
Il 25/04/2018 20:40, Maxime Ripard ha scritto:
Hi Giulio,
On Tue, Apr 24, 2018 at 08:31:44PM +0200, Giulio Benetti wrote:
quoted
LiNova1 is not a board with various headers to connect other peripherals
such display, pcap etc.
It's an HMI that I would consider the same as a Tablet, because it has a
plastic enclosure also.
So I would like to understand how to manage it in the best way.
Try to consider LiNova1 as a Tablet series, with following list:
LiNova1 4.3" ctp
LiNova1 7" ctp
LiNova1 10.1" ctp
LiNova1 4.3" rtp
LiNova1 7" rtp
LiNova1 10.1" rtp
Every of those has a slightly different BOM, so they are 6 different
boards with a common base(uP, ram). And same pcb.
So the LiNova1 is exactly the same in all these setups, the only
difference is that it has a connector that you connect a different
display / touchscreen to?
If so, that's definitely a case for device tree overlays.
Yes it is that way. So I proceed with dt overlays.
quoted
So I don't know if submit only the common base and provide
separately on our github DT-overlays, or provide as many dts patches
as the HMI number with a base dtsi.
That's really up to you, but the overlays will make this much simpler
to handle precisely because it will reduce the amount of combinations
you have.
You can even reduce it in your case to 5 of them, 3 for each panel and
2 for each touchscreen.
Ah, that's right! Good idea, more "encapsulation".
quoted
Basically Micronova provides entire system without the capability to hack
hardware adding shields of various type.
There are also other 2 LiNova:
LiNova2 and LiNova3
Which SoCs are these boards based on?
A20 on all three. They are slightly between each other.
Some RS485 more, 1 USB more etc.
quoted
So I understand that this could lead to 18 different dts files and 3
dtsi files.
Yeah, I'd really like to keep this under control :)
:)
quoted
But with Tablet it should be the same way. For sure people would be
more interested on famous tablets instead of our HMI.
In the case I need to use dt-overlays, you mean .dto files with
fragments inside loaded by u-boot or runtime, right?
You don't have to handcode the fragments anymore with the new syntax,
and U-Boot makes it really trivial to use if you use the FIT image
format to have multiple overlays bundled in the same image. You can
choose to apply them dynamically, for example based on an EEPROM or
some other metric to see which combination you have.
Ah, this is interesting. I'm going to experiment with that.
quoted
quoted
quoted
quoted
quoted
+&usb_otg {
+ dr_mode = "otg";
You're saying that this is a USB-A connector? Then it's not OTG since
it doesn't have an ID pin, this is an host.
Right, with a special overlay I will activate Usb Device for RNDIS,
so modified as host
That doesn't really make much sense. The USB OTG is wired only using a
daughter board?
My fault, I've meant "peripheral" in one case and "host" in another case.
Usually "host".
Are there problem with this?
There is no daughter board.
If you have an ID pin and the ability to control VBUS, then you don't
need to change the device tree, it's done automatically at runtime by
Linux.
Unfortanetely I don't have ID pin and a common mosfet to control VBUS.
"peripheral" mode should be used only in debug mode,
so right dt-overlay can be written to sd-card by ourself or some of our
customers.
Thank you very much for all clarifications!
Giulio.
You don't have to handcode the fragments anymore with the new syntax,
and U-Boot makes it really trivial to use if you use the FIT image
format to have multiple overlays bundled in the same image. You can
choose to apply them dynamically, for example based on an EEPROM or
some other metric to see which combination you have.
Ah, this is interesting. I'm going to experiment with that.
I'm struggling against this, I don't really know how to proceed,
except keeping monolithic dts files including other dtsi files.
About dt-overlays I've tried to look around lot of time,
but the only thing I've found is this:
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/arch/arm/boot/dts?h=topic/renesas-overlays
where they use .dtso tagging them as "/plugin/;"
and compile all .dtso found in dts folder.
Then they obtain .dtbo files that should be the dt-overlays we have
spoken about right?
What I can't understand is if there's a real standard at this time to
follow, because on renesas-driver they use their way to handle all .dtso
files, but on mainline there seems to be nothing about that.
So at the moment I'm trying to compile dts tagged as /plugin/;
but dtc gives me a lot of warnings.
dts:
"
/dts-v1/;
/plugin/;
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
&i2c2 {
pinctrl-names = "default";
pinctrl-0 = <&i2c2_pins_a>;
status = "okay";
ft5x {
compatible = "edt,edt-ft5306";
reg = <0x38>;
interrupt-parent = <&pio>;
interrupts = <7 2 IRQ_TYPE_EDGE_FALLING>; /* PH2 */
reset-gpios = <&pio 7 3 GPIO_ACTIVE_LOW>; /* PH3 */
touchscreen-size-x = <480>;
touchscreen-size-y = <272>;
};
};
"
Build output issuing make ARCH=arm CROSS_COMPILE=arm-linux- aaa.dtb (I
use aaa.dts as source):
"
arch/arm/boot/dts/aaa.dtb: Warning (reg_format):
/fragment@0/__overlay__/ft5x:reg: property has invalid length (4 bytes)
(#address-cells == 2, #size-cells == 1)
arch/arm/boot/dts/aaa.dtb: Warning (pci_device_bus_num): Failed
prerequisite 'reg_format'
arch/arm/boot/dts/aaa.dtb: Warning (simple_bus_reg): Failed prerequisite
'reg_format'
arch/arm/boot/dts/aaa.dtb: Warning (avoid_default_addr_size):
/fragment@0/__overlay__/ft5x: Relying on default #address-cells value
arch/arm/boot/dts/aaa.dtb: Warning (avoid_default_addr_size):
/fragment@0/__overlay__/ft5x: Relying on default #size-cells value
"
Then in uboot I'm trying to do as follows:
# fdt addr 0x43000000 (where dtb is)
# fdt resize 8192
# fdt apply 0x430c0000 (where dtbo is)
But it gives me "libfdt fdt_check_header(): FDT_ERR_BADMAGIC"
(I was expecting some error)
Is there anywhere a guide for this?
Is this what you've meant before?
Using FIT for my use is not the best, so I would like to have many
overlays in /boot folder and use different boot.scr depending on hardware.
Can you point me to somewhere or something?
I don't really know where to beat my head!
Thanks in advance.
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Maxime Ripard <hidden> Date: 2018-05-04 08:07:07
Hi,
On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote:
quoted
quoted
You don't have to handcode the fragments anymore with the new syntax,
and U-Boot makes it really trivial to use if you use the FIT image
format to have multiple overlays bundled in the same image. You can
choose to apply them dynamically, for example based on an EEPROM or
some other metric to see which combination you have.
Ah, this is interesting. I'm going to experiment with that.
I'm struggling against this, I don't really know how to proceed,
except keeping monolithic dts files including other dtsi files.
About dt-overlays I've tried to look around lot of time,
but the only thing I've found is this:
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/arch/arm/boot/dts?h=topic/renesas-overlays
where they use .dtso tagging them as "/plugin/;"
and compile all .dtso found in dts folder.
Then they obtain .dtbo files that should be the dt-overlays we have spoken
about right?
Yes. You don't have to do that though, you can just rely on dtc to
compile them, outside of the linux build system.
What I can't understand is if there's a real standard at this time to
follow, because on renesas-driver they use their way to handle all .dtso
files, but on mainline there seems to be nothing about that.
I'm not sure what you mean here. It's just fragments of device tree,
that have to be compiled using dtc, that's it. You can use the Linux
build system infrastructure to do that, or you can build your own
simpler one. That's really up to you. See for example
https://github.com/NextThingCo/CHIP-dt-overlays/blob/master/Makefile
(even though the overlays themselves use the legacy syntax and
shouldn't really be used an examples)
So at the moment I'm trying to compile dts tagged as /plugin/;
but dtc gives me a lot of warnings.
dts:
"
/dts-v1/;
/plugin/;
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
&i2c2 {
pinctrl-names = "default";
pinctrl-0 = <&i2c2_pins_a>;
status = "okay";
ft5x {
compatible = "edt,edt-ft5306";
reg = <0x38>;
interrupt-parent = <&pio>;
interrupts = <7 2 IRQ_TYPE_EDGE_FALLING>; /* PH2 */
reset-gpios = <&pio 7 3 GPIO_ACTIVE_LOW>; /* PH3 */
touchscreen-size-x = <480>;
touchscreen-size-y = <272>;
};
};
"
Build output issuing make ARCH=arm CROSS_COMPILE=arm-linux- aaa.dtb (I use
aaa.dts as source):
"
arch/arm/boot/dts/aaa.dtb: Warning (reg_format):
/fragment@0/__overlay__/ft5x:reg: property has invalid length (4 bytes)
(#address-cells == 2, #size-cells == 1)
arch/arm/boot/dts/aaa.dtb: Warning (pci_device_bus_num): Failed prerequisite
'reg_format'
arch/arm/boot/dts/aaa.dtb: Warning (simple_bus_reg): Failed prerequisite
'reg_format'
arch/arm/boot/dts/aaa.dtb: Warning (avoid_default_addr_size):
/fragment@0/__overlay__/ft5x: Relying on default #address-cells value
arch/arm/boot/dts/aaa.dtb: Warning (avoid_default_addr_size):
/fragment@0/__overlay__/ft5x: Relying on default #size-cells value
"
Yeah, your i2c node doesn't have the right address-cells and
size-cells properties value, like dtc is telling you.
Then in uboot I'm trying to do as follows:
# fdt addr 0x43000000 (where dtb is)
# fdt resize 8192
# fdt apply 0x430c0000 (where dtbo is)
But it gives me "libfdt fdt_check_header(): FDT_ERR_BADMAGIC"
(I was expecting some error)
It looks like your overlay hasn't been properly loaded.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
Hi Maxime!
Il 04/05/2018 10:06, Maxime Ripard ha scritto:
Hi,
On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote:
quoted
quoted
quoted
You don't have to handcode the fragments anymore with the new syntax,
and U-Boot makes it really trivial to use if you use the FIT image
format to have multiple overlays bundled in the same image. You can
choose to apply them dynamically, for example based on an EEPROM or
some other metric to see which combination you have.
Ah, this is interesting. I'm going to experiment with that.
I'm struggling against this, I don't really know how to proceed,
except keeping monolithic dts files including other dtsi files.
About dt-overlays I've tried to look around lot of time,
but the only thing I've found is this:
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/arch/arm/boot/dts?h=topic/renesas-overlays
where they use .dtso tagging them as "/plugin/;"
and compile all .dtso found in dts folder.
Then they obtain .dtbo files that should be the dt-overlays we have spoken
about right?
Yes. You don't have to do that though, you can just rely on dtc to
compile them, outside of the linux build system.
quoted
What I can't understand is if there's a real standard at this time to
follow, because on renesas-driver they use their way to handle all .dtso
files, but on mainline there seems to be nothing about that.
I'm not sure what you mean here. It's just fragments of device tree,
that have to be compiled using dtc, that's it. You can use the Linux
build system infrastructure to do that, or you can build your own
simpler one. That's really up to you. See for example
https://github.com/NextThingCo/CHIP-dt-overlays/blob/master/Makefile
(even though the overlays themselves use the legacy syntax and
shouldn't really be used an examples)
Everything works now!
Thank you very much!
I've setted up a Repo on Github to give an example on how make it work
with no pain:
https://github.com/micronovasrl/linova-dtoverlays
At the moment it's a mess all around, but it's working and give an idea
on how to make it work. Though I'm going to clean it up well as a base
for linova dtoverlays.
Ah, btw, can you confirm me that base dts file must be compiled outside
kernel with:
dtc -@ ....
Otherwise as in-tree dts with make dtbs "-@" argument is not passed.
Right?
Thank you a lot for your help and time again!
Best regards!
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi, Giulio,
On 05/05/2018 12:52 AM, Giulio Benetti wrote:
Hi Maxime!
Il 04/05/2018 10:06, Maxime Ripard ha scritto:
quoted
Hi,
On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote:
quoted
quoted
quoted
You don't have to handcode the fragments anymore with the new syntax,
and U-Boot makes it really trivial to use if you use the FIT image
format to have multiple overlays bundled in the same image. You can
choose to apply them dynamically, for example based on an EEPROM or
some other metric to see which combination you have.
Ah, this is interesting. I'm going to experiment with that.
I'm struggling against this, I don't really know how to proceed,
except keeping monolithic dts files including other dtsi files.
About dt-overlays I've tried to look around lot of time,
but the only thing I've found is this:
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/arch/arm/boot/dts?h=topic/renesas-overlays
where they use .dtso tagging them as "/plugin/;"
and compile all .dtso found in dts folder.
Then they obtain .dtbo files that should be the dt-overlays we have
spoken
about right?
Yes. You don't have to do that though, you can just rely on dtc to
compile them, outside of the linux build system.
quoted
What I can't understand is if there's a real standard at this time to
follow, because on renesas-driver they use their way to handle all
.dtso
files, but on mainline there seems to be nothing about that.
I'm not sure what you mean here. It's just fragments of device tree,
that have to be compiled using dtc, that's it. You can use the Linux
build system infrastructure to do that, or you can build your own
simpler one. That's really up to you. See for example
https://github.com/NextThingCo/CHIP-dt-overlays/blob/master/Makefile
(even though the overlays themselves use the legacy syntax and
shouldn't really be used an examples)
Everything works now!
Thank you very much!
I've setted up a Repo on Github to give an example on how make it work
with no pain:
https://github.com/micronovasrl/linova-dtoverlays
At the moment it's a mess all around, but it's working and give an
idea on how to make it work. Though I'm going to clean it up well as a
base for linova dtoverlays.
Ah, btw, can you confirm me that base dts file must be compiled
outside kernel with:
dtc -@ ....
Otherwise as in-tree dts with make dtbs "-@" argument is not passed.
Right?
Thank you a lot for your help and time again!
Best regards!
Hi Sergey,
Il 04/05/2018 23:59, Sergey Suloev ha scritto:
Hi, Giulio,
On 05/05/2018 12:52 AM, Giulio Benetti wrote:
quoted
Hi Maxime!
Il 04/05/2018 10:06, Maxime Ripard ha scritto:
quoted
Hi,
On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote:
quoted
quoted
quoted
You don't have to handcode the fragments anymore with the new syntax,
and U-Boot makes it really trivial to use if you use the FIT image
format to have multiple overlays bundled in the same image. You can
choose to apply them dynamically, for example based on an EEPROM or
some other metric to see which combination you have.
Ah, this is interesting. I'm going to experiment with that.
I'm struggling against this, I don't really know how to proceed,
except keeping monolithic dts files including other dtsi files.
About dt-overlays I've tried to look around lot of time,
but the only thing I've found is this:
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/arch/arm/boot/dts?h=topic/renesas-overlays
where they use .dtso tagging them as "/plugin/;"
and compile all .dtso found in dts folder.
Then they obtain .dtbo files that should be the dt-overlays we have
spoken
about right?
Yes. You don't have to do that though, you can just rely on dtc to
compile them, outside of the linux build system.
quoted
What I can't understand is if there's a real standard at this time to
follow, because on renesas-driver they use their way to handle all
.dtso
files, but on mainline there seems to be nothing about that.
I'm not sure what you mean here. It's just fragments of device tree,
that have to be compiled using dtc, that's it. You can use the Linux
build system infrastructure to do that, or you can build your own
simpler one. That's really up to you. See for example
https://github.com/NextThingCo/CHIP-dt-overlays/blob/master/Makefile
(even though the overlays themselves use the legacy syntax and
shouldn't really be used an examples)
Everything works now!
Thank you very much!
I've setted up a Repo on Github to give an example on how make it work
with no pain:
https://github.com/micronovasrl/linova-dtoverlays
At the moment it's a mess all around, but it's working and give an
idea on how to make it work. Though I'm going to clean it up well as a
base for linova dtoverlays.
Ah, btw, can you confirm me that base dts file must be compiled
outside kernel with:
dtc -@ ....
Otherwise as in-tree dts with make dtbs "-@" argument is not passed.
Right?
Thank you a lot for your help and time again!
Best regards!
Thanks for pointing me that,
but as we've discussed before, at the moment overlays are not going to
be included in Mainline Kernel(Maxime correct if I'm wrong).
Try to think maintaining thousands and thousands of overlays,
it would be a nightmare(IMHO).
Maybe it will change, I don't know.
Thanks anyway.
Best regards
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Maxime Ripard <hidden> Date: 2018-05-07 07:30:29
On Fri, May 04, 2018 at 11:52:59PM +0200, Giulio Benetti wrote:
Hi Maxime!
Il 04/05/2018 10:06, Maxime Ripard ha scritto:
quoted
Hi,
On Wed, May 02, 2018 at 06:41:34PM +0200, Giulio Benetti wrote:
quoted
quoted
quoted
You don't have to handcode the fragments anymore with the new syntax,
and U-Boot makes it really trivial to use if you use the FIT image
format to have multiple overlays bundled in the same image. You can
choose to apply them dynamically, for example based on an EEPROM or
some other metric to see which combination you have.
Ah, this is interesting. I'm going to experiment with that.
I'm struggling against this, I don't really know how to proceed,
except keeping monolithic dts files including other dtsi files.
About dt-overlays I've tried to look around lot of time,
but the only thing I've found is this:
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/arch/arm/boot/dts?h=topic/renesas-overlays
where they use .dtso tagging them as "/plugin/;"
and compile all .dtso found in dts folder.
Then they obtain .dtbo files that should be the dt-overlays we have spoken
about right?
Yes. You don't have to do that though, you can just rely on dtc to
compile them, outside of the linux build system.
quoted
What I can't understand is if there's a real standard at this time to
follow, because on renesas-driver they use their way to handle all .dtso
files, but on mainline there seems to be nothing about that.
I'm not sure what you mean here. It's just fragments of device tree,
that have to be compiled using dtc, that's it. You can use the Linux
build system infrastructure to do that, or you can build your own
simpler one. That's really up to you. See for example
https://github.com/NextThingCo/CHIP-dt-overlays/blob/master/Makefile
(even though the overlays themselves use the legacy syntax and
shouldn't really be used an examples)
Everything works now!
Thank you very much!
I've setted up a Repo on Github to give an example on how make it work with
no pain:
https://github.com/micronovasrl/linova-dtoverlays
At the moment it's a mess all around, but it's working and give an idea on
how to make it work. Though I'm going to clean it up well as a base for
linova dtoverlays.
Ah, btw, can you confirm me that base dts file must be compiled outside
kernel with:
dtc -@ ....
Otherwise as in-tree dts with make dtbs "-@" argument is not passed.
Right?
You should use DTC_FLAGS='-@'
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
The A20-Linova1-4_3 HMI, also called Q027_2_A which is printed on
production label, is an industrial Human Machine Interface.
It features:
- 512MB DDR RAM
- 1 Sd-card >= 4GB
- 1 Usb otg(programmable via software) with A-Usb Connector
- 1 Usb host
- 1 Buzzer
- 1 Input for LiPo
- 1 Relay to signal absence of power supply
- 1 External Rtc with 56 bytes of ram + CR2032 battery
- 1 4.3" 24-bits Tft 480x272 with PCap on
- 1 Mono audio 1-watt amplifier
- 1 RS485 port
- 1 Power On Line through +12Vdc reaching 57.600baud,
from where it can be supplied and placed in a network of 50 units
- exposed jtag pins
HMI is supplied from +12Vdc.
Ethernet is absent, so for debugging, need to enable rndis on Usb otg
port through an A-A usb cable.
It comes in different flavours for connector types and can be found with
umounted features as requested by customers.
Signed-off-by: Giulio Benetti <redacted>
---
.../devicetree/bindings/arm/micronova.txt | 6 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun7i-a20-linova1-ctp-4_3i.dts | 192 +++++++++++++++++++++
3 files changed, 199 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/micronova.txt
create mode 100644 arch/arm/boot/dts/sun7i-a20-linova1-ctp-4_3i.dts
From: Rob Herring <robh@kernel.org> Date: 2018-03-26 22:29:10
On Wed, Mar 21, 2018 at 09:03:12PM +0100, Giulio Benetti wrote:
quoted hunk
The A20-Linova1-4_3 HMI, also called Q027_2_A which is printed on
production label, is an industrial Human Machine Interface.
It features:
- 512MB DDR RAM
- 1 Sd-card >= 4GB
- 1 Usb otg(programmable via software) with A-Usb Connector
- 1 Usb host
- 1 Buzzer
- 1 Input for LiPo
- 1 Relay to signal absence of power supply
- 1 External Rtc with 56 bytes of ram + CR2032 battery
- 1 4.3" 24-bits Tft 480x272 with PCap on
- 1 Mono audio 1-watt amplifier
- 1 RS485 port
- 1 Power On Line through +12Vdc reaching 57.600baud,
from where it can be supplied and placed in a network of 50 units
- exposed jtag pins
HMI is supplied from +12Vdc.
Ethernet is absent, so for debugging, need to enable rndis on Usb otg
port through an A-A usb cable.
It comes in different flavours for connector types and can be found with
umounted features as requested by customers.
Signed-off-by: Giulio Benetti <redacted>
---
.../devicetree/bindings/arm/micronova.txt | 6 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun7i-a20-linova1-ctp-4_3i.dts | 192 +++++++++++++++++++++
3 files changed, 199 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/micronova.txt
create mode 100644 arch/arm/boot/dts/sun7i-a20-linova1-ctp-4_3i.dts
It would be more consistent with other pins definitions to have
underscores in both names and to indicate the index, such as:
lcd0_rgb888_pins: lcd0_rgb888_pins@0 {
This way, other set of pins for LCD (PH0-PH27) can be declared as @1
when they are needed in the future.
It would be more consistent with other pins definitions to have
underscores in both names and to indicate the index, such as:
lcd0_rgb888_pins: lcd0_rgb888_pins@0 {
Both your suggestions will generate DTC warnings, and we'd like to get
rid of them eventually :)
This way, other set of pins for LCD (PH0-PH27) can be declared as @1
when they are needed in the future.
A better idea would be to call it lcd0-rgb888-pd-pins, and introduce
the ph variant when it's done.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
It would be more consistent with other pins definitions to have
underscores in both names and to indicate the index, such as:
lcd0_rgb888_pins: lcd0_rgb888_pins@0 {
Both your suggestions will generate DTC warnings, and we'd like to get
rid of them eventually :)
quoted
This way, other set of pins for LCD (PH0-PH27) can be declared as @1
when they are needed in the future.
A better idea would be to call it lcd0-rgb888-pd-pins, and introduce
the ph variant when it's done.
As I know, only PD is muxed with LCD0.
And PH is for LCD1 only.
And LCD0 seems to come out only from PD port according to datasheet,
this is why I didn't put @0 after lcd0-rgb888-pins.
So I don't think it makes sense to handle pins in the way Paul suggests.
What do you all think?
Giulio
Maxime
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
It would be more consistent with other pins definitions to have
underscores in both names and to indicate the index, such as:
lcd0_rgb888_pins: lcd0_rgb888_pins@0 {
Both your suggestions will generate DTC warnings, and we'd like to get
rid of them eventually :)
quoted
This way, other set of pins for LCD (PH0-PH27) can be declared as @1
when they are needed in the future.
A better idea would be to call it lcd0-rgb888-pd-pins, and introduce
the ph variant when it's done.
As I know, only PD is muxed with LCD0.
And PH is for LCD1 only.
And LCD0 seems to come out only from PD port according to datasheet,
this is why I didn't put @0 after lcd0-rgb888-pins.
So I don't think it makes sense to handle pins in the way Paul suggests.
What do you all think?
y
That seems sensible in this case, yes.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
@@ -0,0 +1,7 @@+CDTech(H.K.) Electronics Limited 7" 800x480 color TFT-LCD panel++Required properties:+- compatible: should be "cdtech,s070wv95-ct16"++This binding is compatible with the simple-panel binding, which is specified+in simple-panel.txt in this directory.
@@ -0,0 +1,7 @@+CDTech(H.K.) Electronics Limited 7" 800x480 color TFT-LCD panel++Required properties:+- compatible: should be "cdtech,s070wv95-ct16"++This binding is compatible with the simple-panel binding, which is specified+in simple-panel.txt in this directory.
Please be specific as to what properties apply. In particular, are you
not describing the power supply and it has multiple supplies or the
panel has a single supply?
Rob
On Wed, Mar 21, 2018 at 09:03:07PM +0100, Giulio Benetti wrote:
quoted
This adds a vendor prefix "cdtech" for CDTech(H.K.) Electronics Limited
Would be good to have website and/or info about what this company does.
Do you mean to have it in commit log?
I ask you because I can resubmit this patch with the others since I have
to do v2 patchset.
Thanks
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
In any case,
Reviewed-by: Rob Herring <robh@kernel.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html