All of lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [PATCH 1/1] add sunxi-mali mainline kernel
@ 2017-11-05 22:19 Giulio Benetti
  2017-11-08 10:27 ` Maxime Ripard
  0 siblings, 1 reply; 10+ messages in thread
From: Giulio Benetti @ 2017-11-05 22:19 UTC (permalink / raw)
  To: buildroot

Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
---
 package/sunxi-mali-driver-mainline/Config.in       |  9 +++++
 package/sunxi-mali-driver-mainline/S80mali         | 43 ++++++++++++++++++++++
 .../sunxi-mali-driver-mainline.mk                  | 43 ++++++++++++++++++++++
 3 files changed, 95 insertions(+)
 create mode 100644 package/sunxi-mali-driver-mainline/Config.in
 create mode 100644 package/sunxi-mali-driver-mainline/S80mali
 create mode 100644 package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk

diff --git a/package/sunxi-mali-driver-mainline/Config.in b/package/sunxi-mali-driver-mainline/Config.in
new file mode 100644
index 0000000..8f2c960
--- /dev/null
+++ b/package/sunxi-mali-driver-mainline/Config.in
@@ -0,0 +1,9 @@
+comment "sunxi-mali-driver-mainline needs a Linux kernel to be built"
+	depends on !BR2_LINUX_KERNEL
+
+config BR2_PACKAGE_SUNXI_MALI_DRIVER_MAINLINE
+	bool "sunxi-mali-driver-mainline"
+	depends on BR2_LINUX_KERNEL
+	select BR2_LINUX_NEEDS_MODULES # not using kernel-module infra
+	help
+	  Sunxi Mali Kernel space driver
diff --git a/package/sunxi-mali-driver-mainline/S80mali b/package/sunxi-mali-driver-mainline/S80mali
new file mode 100644
index 0000000..3db342e
--- /dev/null
+++ b/package/sunxi-mali-driver-mainline/S80mali
@@ -0,0 +1,43 @@
+#!/bin/sh -e
+
+install_driver() {
+	DRIVER=$1
+	OPTS=$2
+
+	modprobe $DRIVER $OPTS
+	maj=$(awk "\$2==\"${DRIVER}\" { print \$1; }" /proc/devices)
+
+	rm -f /dev/${DRIVER}
+
+	mknod /dev/${DRIVER} c $maj 0
+	chmod 600 /dev/${DRIVER}
+}
+
+start() {
+	echo "mali: starting driver"
+
+	install_driver mali
+}
+
+stop() {
+	echo "mali: stopping driver"
+
+	rmmod mali
+}
+
+case "$1" in
+start)
+	start
+;;
+stop)
+	stop
+;;
+restart)
+	stop
+	start
+;;
+*)
+	echo "mali: Please use start, stop, or restart."
+	exit 1
+;;
+esac
diff --git a/package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk b/package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk
new file mode 100644
index 0000000..73f7359
--- /dev/null
+++ b/package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk
@@ -0,0 +1,43 @@
+################################################################################
+#
+# sunxi-mali-driver-mainline
+#
+################################################################################
+
+# last sha1 character dropped to ensure unique filename
+SUNXI_MALI_DRIVER_MAINLINE_VERSION = 88ba3cecfc7082bf8e52d7ded16cbbf0ef9e6ca
+SUNXI_MALI_DRIVER_MAINLINE_SITE = https://github.com/mripard/sunxi-mali.git
+SUNXI_MALI_DRIVER_MAINLINE_SITE_METHOD = git
+
+SUNXI_MALI_DRIVER_MAINLINE_DEPENDENCIES = linux
+
+SUNXI_MALI_DRIVER_MAINLINE_MAKE_OPTS = \
+	KDIR=$(LINUX_DIR) \
+	USING_UMP=0 \
+	BUILD=release \
+	USING_DVFS=1 \
+	USING_DEVFREQ=1 \
+	CROSS_COMPILE=$(TARGET_CROSS)
+
+define SUNXI_MALI_DRIVER_MAINLINE_BUILD_CMDS
+	$(APPLY_PATCHES) $(@D)/r6p2 $(@D)/patches \*.patch
+
+	$(SUNXI_MALI_MAINLINE_MAKE_ENV) $(MAKE) \
+		$(SUNXI_MALI_DRIVER_MAINLINE_MAKE_OPTS) \
+		-C $(@D)/r6p2/src/devicedrv/mali
+endef
+
+define SUNXI_MALI_DRIVER_MAINLINE_INSTALL_TARGET_CMDS
+	mkdir -p $(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED)/kernel/gpu/
+
+	cp $(@D)/r6p2/src/devicedrv/mali/mali.ko \
+		$(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED)/kernel/gpu/
+
+	echo kernel/gpu/mali.ko >> \
+	$(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED)/modules.dep
+
+	$(INSTALL) -D -m 0755 package/sunxi-mali-driver-mainline/S80mali \
+		$(TARGET_DIR)/etc/init.d/S80mali
+endef
+
+$(eval $(generic-package))
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 10+ messages in thread
* [Buildroot] [PATCH 1/1] add sunxi-mali mainline kernel
  2017-11-05 22:19 [Buildroot] [PATCH 1/1] add sunxi-mali mainline kernel Giulio Benetti
@ 2017-11-08 10:27 ` Maxime Ripard
  2017-11-08 17:02   ` Giulio Benetti
                     ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Maxime Ripard @ 2017-11-08 10:27 UTC (permalink / raw)
  To: buildroot

Hi,

On Sun, Nov 05, 2017 at 11:19:13PM +0100, Giulio Benetti wrote:
> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>

A commit log would be nice.

> ---
>  package/sunxi-mali-driver-mainline/Config.in       |  9 +++++
>  package/sunxi-mali-driver-mainline/S80mali         | 43 ++++++++++++++++++++++
>  .../sunxi-mali-driver-mainline.mk                  | 43 ++++++++++++++++++++++
>  3 files changed, 95 insertions(+)
>  create mode 100644 package/sunxi-mali-driver-mainline/Config.in
>  create mode 100644 package/sunxi-mali-driver-mainline/S80mali
>  create mode 100644 package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk
> 
> diff --git a/package/sunxi-mali-driver-mainline/Config.in b/package/sunxi-mali-driver-mainline/Config.in
> new file mode 100644
> index 0000000..8f2c960
> --- /dev/null
> +++ b/package/sunxi-mali-driver-mainline/Config.in
> @@ -0,0 +1,9 @@
> +comment "sunxi-mali-driver-mainline needs a Linux kernel to be built"
> +	depends on !BR2_LINUX_KERNEL
> +
> +config BR2_PACKAGE_SUNXI_MALI_DRIVER_MAINLINE
> +	bool "sunxi-mali-driver-mainline"
> +	depends on BR2_LINUX_KERNEL
> +	select BR2_LINUX_NEEDS_MODULES # not using kernel-module infra
> +	help
> +	  Sunxi Mali Kernel space driver
> diff --git a/package/sunxi-mali-driver-mainline/S80mali b/package/sunxi-mali-driver-mainline/S80mali
> new file mode 100644
> index 0000000..3db342e
> --- /dev/null
> +++ b/package/sunxi-mali-driver-mainline/S80mali
> @@ -0,0 +1,43 @@
> +#!/bin/sh -e
> +
> +install_driver() {
> +	DRIVER=$1
> +	OPTS=$2
> +
> +	modprobe $DRIVER $OPTS
> +	maj=$(awk "\$2==\"${DRIVER}\" { print \$1; }" /proc/devices)
> +
> +	rm -f /dev/${DRIVER}
> +
> +	mknod /dev/${DRIVER} c $maj 0
> +	chmod 600 /dev/${DRIVER}
> +}
> +
> +start() {
> +	echo "mali: starting driver"
> +
> +	install_driver mali
> +}
> +
> +stop() {
> +	echo "mali: stopping driver"
> +
> +	rmmod mali
> +}
> +
> +case "$1" in
> +start)
> +	start
> +;;
> +stop)
> +	stop
> +;;
> +restart)
> +	stop
> +	start
> +;;
> +*)
> +	echo "mali: Please use start, stop, or restart."
> +	exit 1
> +;;
> +esac

Why do you need that script? The only thing it does apparently is to
create the device node, which is useless since devtmpfs will do it for
you, and to load the module, which might or might not be needed (if
you have udev for example).

> diff --git a/package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk b/package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk
> new file mode 100644
> index 0000000..73f7359
> --- /dev/null
> +++ b/package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk
> @@ -0,0 +1,43 @@
> +################################################################################
> +#
> +# sunxi-mali-driver-mainline
> +#
> +################################################################################
> +
> +# last sha1 character dropped to ensure unique filename

What do you mean?

> +SUNXI_MALI_DRIVER_MAINLINE_VERSION = 88ba3cecfc7082bf8e52d7ded16cbbf0ef9e6ca
> +SUNXI_MALI_DRIVER_MAINLINE_SITE = https://github.com/mripard/sunxi-mali.git
> +SUNXI_MALI_DRIVER_MAINLINE_SITE_METHOD = git

You can use the github macros to do that.

> +
> +SUNXI_MALI_DRIVER_MAINLINE_DEPENDENCIES = linux
> +
> +SUNXI_MALI_DRIVER_MAINLINE_MAKE_OPTS = \
> +	KDIR=$(LINUX_DIR) \
> +	USING_UMP=0 \
> +	BUILD=release \
> +	USING_DVFS=1 \
> +	USING_DEVFREQ=1 \
> +	CROSS_COMPILE=$(TARGET_CROSS)
> +
> +define SUNXI_MALI_DRIVER_MAINLINE_BUILD_CMDS
> +	$(APPLY_PATCHES) $(@D)/r6p2 $(@D)/patches \*.patch
> +
> +	$(SUNXI_MALI_MAINLINE_MAKE_ENV) $(MAKE) \
> +		$(SUNXI_MALI_DRIVER_MAINLINE_MAKE_OPTS) \
> +		-C $(@D)/r6p2/src/devicedrv/mali
> +endef
> +
> +define SUNXI_MALI_DRIVER_MAINLINE_INSTALL_TARGET_CMDS
> +	mkdir -p $(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED)/kernel/gpu/
> +
> +	cp $(@D)/r6p2/src/devicedrv/mali/mali.ko \
> +		$(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED)/kernel/gpu/
> +
> +	echo kernel/gpu/mali.ko >> \
> +	$(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED)/modules.dep

Why not using the build script that does all this already?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20171108/f80cea1d/attachment.asc>

^ permalink raw reply	[flat|nested] 10+ messages in thread
* [Buildroot] [PATCH 1/1] add sunxi-mali mainline kernel
  2017-11-08 10:27 ` Maxime Ripard
@ 2017-11-08 17:02   ` Giulio Benetti
  2017-11-08 23:05   ` Arnout Vandecappelle
  2017-11-08 23:34   ` Giulio Benetti
  2 siblings, 0 replies; 10+ messages in thread
From: Giulio Benetti @ 2017-11-08 17:02 UTC (permalink / raw)
  To: buildroot

Hi,

Il 08/11/2017 11:27, Maxime Ripard ha scritto:
> Hi,
> 
> On Sun, Nov 05, 2017 at 11:19:13PM +0100, Giulio Benetti wrote:
>> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
> 
> A commit log would be nice.

Right

> 
>> ---
>>   package/sunxi-mali-driver-mainline/Config.in       |  9 +++++
>>   package/sunxi-mali-driver-mainline/S80mali         | 43 ++++++++++++++++++++++
>>   .../sunxi-mali-driver-mainline.mk                  | 43 ++++++++++++++++++++++
>>   3 files changed, 95 insertions(+)
>>   create mode 100644 package/sunxi-mali-driver-mainline/Config.in
>>   create mode 100644 package/sunxi-mali-driver-mainline/S80mali
>>   create mode 100644 package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk
>>
>> diff --git a/package/sunxi-mali-driver-mainline/Config.in b/package/sunxi-mali-driver-mainline/Config.in
>> new file mode 100644
>> index 0000000..8f2c960
>> --- /dev/null
>> +++ b/package/sunxi-mali-driver-mainline/Config.in
>> @@ -0,0 +1,9 @@
>> +comment "sunxi-mali-driver-mainline needs a Linux kernel to be built"
>> +	depends on !BR2_LINUX_KERNEL
>> +
>> +config BR2_PACKAGE_SUNXI_MALI_DRIVER_MAINLINE
>> +	bool "sunxi-mali-driver-mainline"
>> +	depends on BR2_LINUX_KERNEL
>> +	select BR2_LINUX_NEEDS_MODULES # not using kernel-module infra
>> +	help
>> +	  Sunxi Mali Kernel space driver
>> diff --git a/package/sunxi-mali-driver-mainline/S80mali b/package/sunxi-mali-driver-mainline/S80mali
>> new file mode 100644
>> index 0000000..3db342e
>> --- /dev/null
>> +++ b/package/sunxi-mali-driver-mainline/S80mali
>> @@ -0,0 +1,43 @@
>> +#!/bin/sh -e
>> +
>> +install_driver() {
>> +	DRIVER=$1
>> +	OPTS=$2
>> +
>> +	modprobe $DRIVER $OPTS
>> +	maj=$(awk "\$2==\"${DRIVER}\" { print \$1; }" /proc/devices)
>> +
>> +	rm -f /dev/${DRIVER}
>> +
>> +	mknod /dev/${DRIVER} c $maj 0
>> +	chmod 600 /dev/${DRIVER}
>> +}
>> +
>> +start() {
>> +	echo "mali: starting driver"
>> +
>> +	install_driver mali
>> +}
>> +
>> +stop() {
>> +	echo "mali: stopping driver"
>> +
>> +	rmmod mali
>> +}
>> +
>> +case "$1" in
>> +start)
>> +	start
>> +;;
>> +stop)
>> +	stop
>> +;;
>> +restart)
>> +	stop
>> +	start
>> +;;
>> +*)
>> +	echo "mali: Please use start, stop, or restart."
>> +	exit 1
>> +;;
>> +esac
> 
> Why do you need that script? The only thing it does apparently is to
> create the device node, which is useless since devtmpfs will do it for
> you, and to load the module, which might or might not be needed (if
> you have udev for example).

I agree with you, in fact I only took as a legacy from sunxi-mali,
but better to remove it.

> 
>> diff --git a/package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk b/package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk
>> new file mode 100644
>> index 0000000..73f7359
>> --- /dev/null
>> +++ b/package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk
>> @@ -0,0 +1,43 @@
>> +################################################################################
>> +#
>> +# sunxi-mali-driver-mainline
>> +#
>> +################################################################################
>> +
>> +# last sha1 character dropped to ensure unique filename
> 
> What do you mean?

Honestly I don't know, this is copied by legacy sunxi-mali.
Better remove and...

> 
>> +SUNXI_MALI_DRIVER_MAINLINE_VERSION = 88ba3cecfc7082bf8e52d7ded16cbbf0ef9e6ca
>> +SUNXI_MALI_DRIVER_MAINLINE_SITE = https://github.com/mripard/sunxi-mali.git
>> +SUNXI_MALI_DRIVER_MAINLINE_SITE_METHOD = git
> 
> You can use the github macros to do that.

sure I will use github macros, forgotten about it.

> 
>> +
>> +SUNXI_MALI_DRIVER_MAINLINE_DEPENDENCIES = linux
>> +
>> +SUNXI_MALI_DRIVER_MAINLINE_MAKE_OPTS = \
>> +	KDIR=$(LINUX_DIR) \
>> +	USING_UMP=0 \
>> +	BUILD=release \
>> +	USING_DVFS=1 \
>> +	USING_DEVFREQ=1 \
>> +	CROSS_COMPILE=$(TARGET_CROSS)
>> +
>> +define SUNXI_MALI_DRIVER_MAINLINE_BUILD_CMDS
>> +	$(APPLY_PATCHES) $(@D)/r6p2 $(@D)/patches \*.patch
>> +
>> +	$(SUNXI_MALI_MAINLINE_MAKE_ENV) $(MAKE) \
>> +		$(SUNXI_MALI_DRIVER_MAINLINE_MAKE_OPTS) \
>> +		-C $(@D)/r6p2/src/devicedrv/mali
>> +endef
>> +
>> +define SUNXI_MALI_DRIVER_MAINLINE_INSTALL_TARGET_CMDS
>> +	mkdir -p $(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED)/kernel/gpu/
>> +
>> +	cp $(@D)/r6p2/src/devicedrv/mali/mali.ko \
>> +		$(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED)/kernel/gpu/
>> +
>> +	echo kernel/gpu/mali.ko >> \
>> +	$(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED)/modules.dep
> 
> Why not using the build script that does all this already?

I misread Makefile, I didn't see that there was modules recipe...
Worked for nothing, I replace with modules pkg-kernel-module.

> 
> Thanks!
> Maxime
> 


-- 
Giulio Benetti
R&D Manager &
Advanced Research

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

^ permalink raw reply	[flat|nested] 10+ messages in thread
* [Buildroot] [PATCH 1/1] add sunxi-mali mainline kernel
  2017-11-08 10:27 ` Maxime Ripard
  2017-11-08 17:02   ` Giulio Benetti
@ 2017-11-08 23:05   ` Arnout Vandecappelle
  2017-11-08 23:15     ` Giulio Benetti
  2017-11-09  8:05     ` Maxime Ripard
  2017-11-08 23:34   ` Giulio Benetti
  2 siblings, 2 replies; 10+ messages in thread
From: Arnout Vandecappelle @ 2017-11-08 23:05 UTC (permalink / raw)
  To: buildroot



On 08-11-17 11:27, Maxime Ripard wrote:
> Hi,
> 
> On Sun, Nov 05, 2017 at 11:19:13PM +0100, Giulio Benetti wrote:
>> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
> 
> A commit log would be nice.

 Yeah, and also a help text. README.md can be an inspiration :-)

> 
>> ---
>>  package/sunxi-mali-driver-mainline/Config.in       |  9 +++++
>>  package/sunxi-mali-driver-mainline/S80mali         | 43 ++++++++++++++++++++++
>>  .../sunxi-mali-driver-mainline.mk                  | 43 ++++++++++++++++++++++
>>  3 files changed, 95 insertions(+)
>>  create mode 100644 package/sunxi-mali-driver-mainline/Config.in
>>  create mode 100644 package/sunxi-mali-driver-mainline/S80mali
>>  create mode 100644 package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk
>>
>> diff --git a/package/sunxi-mali-driver-mainline/Config.in b/package/sunxi-mali-driver-mainline/Config.in
>> new file mode 100644
>> index 0000000..8f2c960
>> --- /dev/null
>> +++ b/package/sunxi-mali-driver-mainline/Config.in
>> @@ -0,0 +1,9 @@
>> +comment "sunxi-mali-driver-mainline needs a Linux kernel to be built"
>> +	depends on !BR2_LINUX_KERNEL
>> +
>> +config BR2_PACKAGE_SUNXI_MALI_DRIVER_MAINLINE
>> +	bool "sunxi-mali-driver-mainline"
>> +	depends on BR2_LINUX_KERNEL
>> +	select BR2_LINUX_NEEDS_MODULES # not using kernel-module infra
>> +	help
>> +	  Sunxi Mali Kernel space driver

 Please also mention in the help text what the kernel requirements are (>= 4.12
I think?)

[snip]
>> diff --git a/package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk b/package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk
>> new file mode 100644
>> index 0000000..73f7359
>> --- /dev/null
>> +++ b/package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk
>> @@ -0,0 +1,43 @@
>> +################################################################################
>> +#
>> +# sunxi-mali-driver-mainline
>> +#
>> +################################################################################
>> +
>> +# last sha1 character dropped to ensure unique filename
> 
> What do you mean?

 See the commit log of 956fcc2100c865b25f97c688f0b9012bbd5dfdb1 - this was to
deal with the github tarball change fallout.

> 
>> +SUNXI_MALI_DRIVER_MAINLINE_VERSION = 88ba3cecfc7082bf8e52d7ded16cbbf0ef9e6ca
>> +SUNXI_MALI_DRIVER_MAINLINE_SITE = https://github.com/mripard/sunxi-mali.git
>> +SUNXI_MALI_DRIVER_MAINLINE_SITE_METHOD = git
> 
> You can use the github macros to do that.
> 
>> +
>> +SUNXI_MALI_DRIVER_MAINLINE_DEPENDENCIES = linux
>> +
>> +SUNXI_MALI_DRIVER_MAINLINE_MAKE_OPTS = \
>> +	KDIR=$(LINUX_DIR) \
>> +	USING_UMP=0 \
>> +	BUILD=release \
>> +	USING_DVFS=1 \
>> +	USING_DEVFREQ=1 \
>> +	CROSS_COMPILE=$(TARGET_CROSS)
>> +
>> +define SUNXI_MALI_DRIVER_MAINLINE_BUILD_CMDS
>> +	$(APPLY_PATCHES) $(@D)/r6p2 $(@D)/patches \*.patch

 Maxime, WTF? Why is this maintained as patches and not as a proper history?

 If it's for rebasing, you can maintain separate branches for the
upstream-tracking and the modified stuff. If it is because the same patches need
to be applied to different upstream versions, you can do it in different
branches and use subtree merge. This applying of patches is really not user
friendly IMO.

 Giulio, the proper way to do this is in a POST_PATCH_HOOK. Otherwise, if you
rebuild it, it will also be patched again (which will fail).

>> +
>> +	$(SUNXI_MALI_MAINLINE_MAKE_ENV) $(MAKE) \
>> +		$(SUNXI_MALI_DRIVER_MAINLINE_MAKE_OPTS) \
>> +		-C $(@D)/r6p2/src/devicedrv/mali

 So why not use the kernel-module infra?

>> +endef
>> +
>> +define SUNXI_MALI_DRIVER_MAINLINE_INSTALL_TARGET_CMDS
>> +	mkdir -p $(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED)/kernel/gpu/
>> +
>> +	cp $(@D)/r6p2/src/devicedrv/mali/mali.ko \
>> +		$(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED)/kernel/gpu/
>> +
>> +	echo kernel/gpu/mali.ko >> \
>> +	$(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED)/modules.dep
> 
> Why not using the build script that does all this already?

 Or the kernel-module infra :-)

 Regards,
 Arnout

> 
> Thanks!
> Maxime
> 
> 
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply	[flat|nested] 10+ messages in thread
* [Buildroot] [PATCH 1/1] add sunxi-mali mainline kernel
  2017-11-08 23:05   ` Arnout Vandecappelle
@ 2017-11-08 23:15     ` Giulio Benetti
  2017-11-09  8:05     ` Maxime Ripard
  1 sibling, 0 replies; 10+ messages in thread
From: Giulio Benetti @ 2017-11-08 23:15 UTC (permalink / raw)
  To: buildroot

Hi Arnout,

Il 09/11/2017 00:05, Arnout Vandecappelle ha scritto:
> 
> 
> On 08-11-17 11:27, Maxime Ripard wrote:
>> Hi,
>>
>> On Sun, Nov 05, 2017 at 11:19:13PM +0100, Giulio Benetti wrote:
>>> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
>>
>> A commit log would be nice.
> 
>   Yeah, and also a help text. README.md can be an inspiration :-)

Ok, I try to find something to inspire on already in buildroot.

> 
>>
>>> ---
>>>   package/sunxi-mali-driver-mainline/Config.in       |  9 +++++
>>>   package/sunxi-mali-driver-mainline/S80mali         | 43 ++++++++++++++++++++++
>>>   .../sunxi-mali-driver-mainline.mk                  | 43 ++++++++++++++++++++++
>>>   3 files changed, 95 insertions(+)
>>>   create mode 100644 package/sunxi-mali-driver-mainline/Config.in
>>>   create mode 100644 package/sunxi-mali-driver-mainline/S80mali
>>>   create mode 100644 package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk
>>>
>>> diff --git a/package/sunxi-mali-driver-mainline/Config.in b/package/sunxi-mali-driver-mainline/Config.in
>>> new file mode 100644
>>> index 0000000..8f2c960
>>> --- /dev/null
>>> +++ b/package/sunxi-mali-driver-mainline/Config.in
>>> @@ -0,0 +1,9 @@
>>> +comment "sunxi-mali-driver-mainline needs a Linux kernel to be built"
>>> +	depends on !BR2_LINUX_KERNEL
>>> +
>>> +config BR2_PACKAGE_SUNXI_MALI_DRIVER_MAINLINE
>>> +	bool "sunxi-mali-driver-mainline"
>>> +	depends on BR2_LINUX_KERNEL
>>> +	select BR2_LINUX_NEEDS_MODULES # not using kernel-module infra
>>> +	help
>>> +	  Sunxi Mali Kernel space driver
> 
>   Please also mention in the help text what the kernel requirements are (>= 4.12
> I think?)

Ok

> 
> [snip]
>>> diff --git a/package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk b/package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk
>>> new file mode 100644
>>> index 0000000..73f7359
>>> --- /dev/null
>>> +++ b/package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk
>>> @@ -0,0 +1,43 @@
>>> +################################################################################
>>> +#
>>> +# sunxi-mali-driver-mainline
>>> +#
>>> +################################################################################
>>> +
>>> +# last sha1 character dropped to ensure unique filename
>>
>> What do you mean?
> 
>   See the commit log of 956fcc2100c865b25f97c688f0b9012bbd5dfdb1 - this was to
> deal with the github tarball change fallout.
> 
>>
>>> +SUNXI_MALI_DRIVER_MAINLINE_VERSION = 88ba3cecfc7082bf8e52d7ded16cbbf0ef9e6ca
>>> +SUNXI_MALI_DRIVER_MAINLINE_SITE = https://github.com/mripard/sunxi-mali.git
>>> +SUNXI_MALI_DRIVER_MAINLINE_SITE_METHOD = git
>>
>> You can use the github macros to do that.
>>
>>> +
>>> +SUNXI_MALI_DRIVER_MAINLINE_DEPENDENCIES = linux
>>> +
>>> +SUNXI_MALI_DRIVER_MAINLINE_MAKE_OPTS = \
>>> +	KDIR=$(LINUX_DIR) \
>>> +	USING_UMP=0 \
>>> +	BUILD=release \
>>> +	USING_DVFS=1 \
>>> +	USING_DEVFREQ=1 \
>>> +	CROSS_COMPILE=$(TARGET_CROSS)
>>> +
>>> +define SUNXI_MALI_DRIVER_MAINLINE_BUILD_CMDS
>>> +	$(APPLY_PATCHES) $(@D)/r6p2 $(@D)/patches \*.patch
> 
>   Maxime, WTF? Why is this maintained as patches and not as a proper history?
> 
>   If it's for rebasing, you can maintain separate branches for the
> upstream-tracking and the modified stuff. If it is because the same patches need
> to be applied to different upstream versions, you can do it in different
> branches and use subtree merge. This applying of patches is really not user
> friendly IMO.

I wait for Maxime to proceed, because different kernel versions,
need different patches.
Maxime, let me know how to proceed,
even if I could be useful for this https://github.com/mripard/sunxi-mali.git

> 
>   Giulio, the proper way to do this is in a POST_PATCH_HOOK. Otherwise, if you
> rebuild it, it will also be patched again (which will fail).

Ok, I didn't know that, and didn't retry to compile twice.

> 
>>> +
>>> +	$(SUNXI_MALI_MAINLINE_MAKE_ENV) $(MAKE) \
>>> +		$(SUNXI_MALI_DRIVER_MAINLINE_MAKE_OPTS) \
>>> +		-C $(@D)/r6p2/src/devicedrv/mali
> 
>   So why not use the kernel-module infra?

I've already answered to Maxime, that's my fault,
I didn't see that in Makefile there is "modules" recipe.

> 
>>> +endef
>>> +
>>> +define SUNXI_MALI_DRIVER_MAINLINE_INSTALL_TARGET_CMDS
>>> +	mkdir -p $(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED)/kernel/gpu/
>>> +
>>> +	cp $(@D)/r6p2/src/devicedrv/mali/mali.ko \
>>> +		$(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED)/kernel/gpu/
>>> +
>>> +	echo kernel/gpu/mali.ko >> \
>>> +	$(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED)/modules.dep
>>
>> Why not using the build script that does all this already?
> 
>   Or the kernel-module infra :-)
> 
>   Regards,
>   Arnout
> 
>>
>> Thanks!
>> Maxime
>>
>>
>>
>> _______________________________________________
>> buildroot mailing list
>> buildroot at busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot
>>
> 

Thanks to everybody

-- 
Giulio Benetti
R&D Manager &
Advanced Research

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

^ permalink raw reply	[flat|nested] 10+ messages in thread
* [Buildroot] [PATCH 1/1] add sunxi-mali mainline kernel
  2017-11-08 10:27 ` Maxime Ripard
  2017-11-08 17:02   ` Giulio Benetti
  2017-11-08 23:05   ` Arnout Vandecappelle
@ 2017-11-08 23:34   ` Giulio Benetti
  2 siblings, 0 replies; 10+ messages in thread
From: Giulio Benetti @ 2017-11-08 23:34 UTC (permalink / raw)
  To: buildroot

Adding Arnout,

Maxime already answered to me about it here.

Il 08/11/2017 11:27, Maxime Ripard ha scritto:
> Hi,
> 
> On Sun, Nov 05, 2017 at 11:19:13PM +0100, Giulio Benetti wrote:
>> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
> 
> A commit log would be nice.
> 
>> ---
>>   package/sunxi-mali-driver-mainline/Config.in       |  9 +++++
>>   package/sunxi-mali-driver-mainline/S80mali         | 43 ++++++++++++++++++++++
>>   .../sunxi-mali-driver-mainline.mk                  | 43 ++++++++++++++++++++++
>>   3 files changed, 95 insertions(+)
>>   create mode 100644 package/sunxi-mali-driver-mainline/Config.in
>>   create mode 100644 package/sunxi-mali-driver-mainline/S80mali
>>   create mode 100644 package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk
>>
>> diff --git a/package/sunxi-mali-driver-mainline/Config.in b/package/sunxi-mali-driver-mainline/Config.in
>> new file mode 100644
>> index 0000000..8f2c960
>> --- /dev/null
>> +++ b/package/sunxi-mali-driver-mainline/Config.in
>> @@ -0,0 +1,9 @@
>> +comment "sunxi-mali-driver-mainline needs a Linux kernel to be built"
>> +	depends on !BR2_LINUX_KERNEL
>> +
>> +config BR2_PACKAGE_SUNXI_MALI_DRIVER_MAINLINE
>> +	bool "sunxi-mali-driver-mainline"
>> +	depends on BR2_LINUX_KERNEL
>> +	select BR2_LINUX_NEEDS_MODULES # not using kernel-module infra
>> +	help
>> +	  Sunxi Mali Kernel space driver
>> diff --git a/package/sunxi-mali-driver-mainline/S80mali b/package/sunxi-mali-driver-mainline/S80mali
>> new file mode 100644
>> index 0000000..3db342e
>> --- /dev/null
>> +++ b/package/sunxi-mali-driver-mainline/S80mali
>> @@ -0,0 +1,43 @@
>> +#!/bin/sh -e
>> +
>> +install_driver() {
>> +	DRIVER=$1
>> +	OPTS=$2
>> +
>> +	modprobe $DRIVER $OPTS
>> +	maj=$(awk "\$2==\"${DRIVER}\" { print \$1; }" /proc/devices)
>> +
>> +	rm -f /dev/${DRIVER}
>> +
>> +	mknod /dev/${DRIVER} c $maj 0
>> +	chmod 600 /dev/${DRIVER}
>> +}
>> +
>> +start() {
>> +	echo "mali: starting driver"
>> +
>> +	install_driver mali
>> +}
>> +
>> +stop() {
>> +	echo "mali: stopping driver"
>> +
>> +	rmmod mali
>> +}
>> +
>> +case "$1" in
>> +start)
>> +	start
>> +;;
>> +stop)
>> +	stop
>> +;;
>> +restart)
>> +	stop
>> +	start
>> +;;
>> +*)
>> +	echo "mali: Please use start, stop, or restart."
>> +	exit 1
>> +;;
>> +esac
> 
> Why do you need that script? The only thing it does apparently is to
> create the device node, which is useless since devtmpfs will do it for
> you, and to load the module, which might or might not be needed (if
> you have udev for example).
> 
>> diff --git a/package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk b/package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk
>> new file mode 100644
>> index 0000000..73f7359
>> --- /dev/null
>> +++ b/package/sunxi-mali-driver-mainline/sunxi-mali-driver-mainline.mk
>> @@ -0,0 +1,43 @@
>> +################################################################################
>> +#
>> +# sunxi-mali-driver-mainline
>> +#
>> +################################################################################
>> +
>> +# last sha1 character dropped to ensure unique filename
> 
> What do you mean?
> 
>> +SUNXI_MALI_DRIVER_MAINLINE_VERSION = 88ba3cecfc7082bf8e52d7ded16cbbf0ef9e6ca
>> +SUNXI_MALI_DRIVER_MAINLINE_SITE = https://github.com/mripard/sunxi-mali.git
>> +SUNXI_MALI_DRIVER_MAINLINE_SITE_METHOD = git
> 
> You can use the github macros to do that.
> 
>> +
>> +SUNXI_MALI_DRIVER_MAINLINE_DEPENDENCIES = linux
>> +
>> +SUNXI_MALI_DRIVER_MAINLINE_MAKE_OPTS = \
>> +	KDIR=$(LINUX_DIR) \
>> +	USING_UMP=0 \
>> +	BUILD=release \
>> +	USING_DVFS=1 \
>> +	USING_DEVFREQ=1 \
>> +	CROSS_COMPILE=$(TARGET_CROSS)
>> +
>> +define SUNXI_MALI_DRIVER_MAINLINE_BUILD_CMDS
>> +	$(APPLY_PATCHES) $(@D)/r6p2 $(@D)/patches \*.patch
>> +
>> +	$(SUNXI_MALI_MAINLINE_MAKE_ENV) $(MAKE) \
>> +		$(SUNXI_MALI_DRIVER_MAINLINE_MAKE_OPTS) \
>> +		-C $(@D)/r6p2/src/devicedrv/mali
>> +endef
>> +
>> +define SUNXI_MALI_DRIVER_MAINLINE_INSTALL_TARGET_CMDS
>> +	mkdir -p $(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED)/kernel/gpu/
>> +
>> +	cp $(@D)/r6p2/src/devicedrv/mali/mali.ko \
>> +		$(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED)/kernel/gpu/
>> +
>> +	echo kernel/gpu/mali.ko >> \
>> +	$(TARGET_DIR)/lib/modules/$(LINUX_VERSION_PROBED)/modules.dep
> 
> Why not using the build script that does all this already?
> 
> Thanks!
> Maxime
> 


-- 
Giulio Benetti
R&D Manager &
Advanced Research

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

^ permalink raw reply	[flat|nested] 10+ messages in thread
* [Buildroot] [PATCH 1/1] add sunxi-mali mainline kernel
  2017-11-08 23:05   ` Arnout Vandecappelle
  2017-11-08 23:15     ` Giulio Benetti
@ 2017-11-09  8:05     ` Maxime Ripard
  2017-11-09 17:00       ` Giulio Benetti
  2017-11-11 10:03       ` Arnout Vandecappelle
  1 sibling, 2 replies; 10+ messages in thread
From: Maxime Ripard @ 2017-11-09  8:05 UTC (permalink / raw)
  To: buildroot

Hi,

On Thu, Nov 09, 2017 at 12:05:23AM +0100, Arnout Vandecappelle wrote:
> >> +++ b/package/sunxi-mali-driver-mainline/Config.in
> >> @@ -0,0 +1,9 @@
> >> +comment "sunxi-mali-driver-mainline needs a Linux kernel to be built"
> >> +	depends on !BR2_LINUX_KERNEL
> >> +
> >> +config BR2_PACKAGE_SUNXI_MALI_DRIVER_MAINLINE
> >> +	bool "sunxi-mali-driver-mainline"
> >> +	depends on BR2_LINUX_KERNEL
> >> +	select BR2_LINUX_NEEDS_MODULES # not using kernel-module infra
> >> +	help
> >> +	  Sunxi Mali Kernel space driver
> 
>  Please also mention in the help text what the kernel requirements
> are (>= 4.12 I think?)

At least as far back as 4.4, but I haven't tried with anything older.

> >> +
> >> +SUNXI_MALI_DRIVER_MAINLINE_DEPENDENCIES = linux
> >> +
> >> +SUNXI_MALI_DRIVER_MAINLINE_MAKE_OPTS = \
> >> +	KDIR=$(LINUX_DIR) \
> >> +	USING_UMP=0 \
> >> +	BUILD=release \
> >> +	USING_DVFS=1 \
> >> +	USING_DEVFREQ=1 \
> >> +	CROSS_COMPILE=$(TARGET_CROSS)
> >> +
> >> +define SUNXI_MALI_DRIVER_MAINLINE_BUILD_CMDS
> >> +	$(APPLY_PATCHES) $(@D)/r6p2 $(@D)/patches \*.patch
> 
>  Maxime, WTF? Why is this maintained as patches and not as a proper history?
> 
>  If it's for rebasing, you can maintain separate branches for the
> upstream-tracking and the modified stuff. If it is because the same patches need
> to be applied to different upstream versions, you can do it in different
> branches and use subtree merge. This applying of patches is really not user
> friendly IMO.

So, while I'm really not happy about the current code, I haven't found
better yet.

The idea is that we have various versions coming from ARM as
tarballs. On this various versions, the changes needed are the same
(but obviously the code to apply it on isn't), and maintaining two
sets of changes (through git commits or something else) would be very
inefficient and wouldn't scale.

So I went for the same set of patches that we apply on whatever
version is currently being built. Like I was saying, I'm not really
happy about it either so I'm definitely open to suggestions. We
discussed it with Thomas quite some time ago and it's the only
solution that stuck.

I didn't know about the git subtrees, but as far as I can see, you
need to have a git upstream, and it's doing a complete merge, so
whenever you would merge the r6p2 changes to the r6p0 version, it
would also bring the rest of the r6p2 code with it, or am I missing
something?

> Giulio, the proper way to do this is in a POST_PATCH_HOOK. Otherwise, if you
> rebuild it, it will also be patched again (which will fail).

We also have a build.sh script that abstracts all this away.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20171109/3307a6c9/attachment.asc>

^ permalink raw reply	[flat|nested] 10+ messages in thread
* [Buildroot] [PATCH 1/1] add sunxi-mali mainline kernel
  2017-11-09  8:05     ` Maxime Ripard
@ 2017-11-09 17:00       ` Giulio Benetti
  2017-11-11 10:03       ` Arnout Vandecappelle
  1 sibling, 0 replies; 10+ messages in thread
From: Giulio Benetti @ 2017-11-09 17:00 UTC (permalink / raw)
  To: buildroot

Hi Maxime,

Il 09/11/2017 09:05, Maxime Ripard ha scritto:
> Hi,
> 
> On Thu, Nov 09, 2017 at 12:05:23AM +0100, Arnout Vandecappelle wrote:
>>>> +++ b/package/sunxi-mali-driver-mainline/Config.in
>>>> @@ -0,0 +1,9 @@
>>>> +comment "sunxi-mali-driver-mainline needs a Linux kernel to be built"
>>>> +	depends on !BR2_LINUX_KERNEL
>>>> +
>>>> +config BR2_PACKAGE_SUNXI_MALI_DRIVER_MAINLINE
>>>> +	bool "sunxi-mali-driver-mainline"
>>>> +	depends on BR2_LINUX_KERNEL
>>>> +	select BR2_LINUX_NEEDS_MODULES # not using kernel-module infra
>>>> +	help
>>>> +	  Sunxi Mali Kernel space driver
>>
>>   Please also mention in the help text what the kernel requirements
>> are (>= 4.12 I think?)
> 
> At least as far back as 4.4, but I haven't tried with anything older.

On v2 patch I will put >=4.4 to begin,
then it could be patched again after testing.

> 
>>>> +
>>>> +SUNXI_MALI_DRIVER_MAINLINE_DEPENDENCIES = linux
>>>> +
>>>> +SUNXI_MALI_DRIVER_MAINLINE_MAKE_OPTS = \
>>>> +	KDIR=$(LINUX_DIR) \
>>>> +	USING_UMP=0 \
>>>> +	BUILD=release \
>>>> +	USING_DVFS=1 \
>>>> +	USING_DEVFREQ=1 \
>>>> +	CROSS_COMPILE=$(TARGET_CROSS)
>>>> +
>>>> +define SUNXI_MALI_DRIVER_MAINLINE_BUILD_CMDS
>>>> +	$(APPLY_PATCHES) $(@D)/r6p2 $(@D)/patches \*.patch
>>
>>   Maxime, WTF? Why is this maintained as patches and not as a proper history?
>>
>>   If it's for rebasing, you can maintain separate branches for the
>> upstream-tracking and the modified stuff. If it is because the same patches need
>> to be applied to different upstream versions, you can do it in different
>> branches and use subtree merge. This applying of patches is really not user
>> friendly IMO.
> 
> So, while I'm really not happy about the current code, I haven't found
> better yet.
> 
> The idea is that we have various versions coming from ARM as
> tarballs. On this various versions, the changes needed are the same
> (but obviously the code to apply it on isn't), and maintaining two
> sets of changes (through git commits or something else) would be very
> inefficient and wouldn't scale.
> 
> So I went for the same set of patches that we apply on whatever
> version is currently being built. Like I was saying, I'm not really
> happy about it either so I'm definitely open to suggestions. We
> discussed it with Thomas quite some time ago and it's the only
> solution that stuck.
> 
> I didn't know about the git subtrees, but as far as I can see, you
> need to have a git upstream, and it's doing a complete merge, so
> whenever you would merge the r6p2 changes to the r6p0 version, it
> would also bring the rest of the r6p2 code with it, or am I missing
> something?
> 
>> Giulio, the proper way to do this is in a POST_PATCH_HOOK. Otherwise, if you
>> rebuild it, it will also be patched again (which will fail).
> 
> We also have a build.sh script that abstracts all this away.

You are right, now I have build.sh script, and everything is easier.
It only needed bash to work.

> 
> Maxime
> 

v2 patch is coming

-- 
Giulio Benetti
R&D Manager &
Advanced Research

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

^ permalink raw reply	[flat|nested] 10+ messages in thread
* [Buildroot] [PATCH 1/1] add sunxi-mali mainline kernel
  2017-11-09  8:05     ` Maxime Ripard
  2017-11-09 17:00       ` Giulio Benetti
@ 2017-11-11 10:03       ` Arnout Vandecappelle
  2017-11-13  9:07         ` Maxime Ripard
  1 sibling, 1 reply; 10+ messages in thread
From: Arnout Vandecappelle @ 2017-11-11 10:03 UTC (permalink / raw)
  To: buildroot



On 09-11-17 09:05, Maxime Ripard wrote:
> So, while I'm really not happy about the current code, I haven't found
> better yet.
> 
> The idea is that we have various versions coming from ARM as
> tarballs. On this various versions, the changes needed are the same
> (but obviously the code to apply it on isn't), and maintaining two
> sets of changes (through git commits or something else) would be very
> inefficient and wouldn't scale.
> 
> So I went for the same set of patches that we apply on whatever
> version is currently being built.

 But it's pretty unlikely that those patches will always apply unmodified on all
versions, right?

> Like I was saying, I'm not really
> happy about it either so I'm definitely open to suggestions. We
> discussed it with Thomas quite some time ago and it's the only
> solution that stuck.

 If I understand correctly, for a specific project you will always use a
specific release (i.e. version coming from ARM), you never need to mix two
releases, right?

 How we solved this for a similar situation with drivers coming from the company
I love so much is as follows. We have an "incoming" branch that just contains
the unmodified code coming from the tarballs. Whenever a new tarball comes in,
you check out that branch, remove everything, untar, git add -A, and commit.
Then, for each release, a new branch is created, by rebasing the old release
branch on top of the new release: git checkout -b r6p2 r6p0; git rebase
incoming. And in the project configuration you check out the branch you need.
If you create a new patch, it needs to be cherry-picked on each branch and this
is indeed annoying. OTOH you need to separately test that new patch on each
release anyway so it's not that much extra effort.

 So our history would look like this (time goes down, columns are branches)

incoming            r5p4           r6p0           r6p2
import r5p4
           -------> create
                    add feat1
                    add feat2
import r6p0
            --------rebase-------->add feat1
                                  >add feat2
                                   add feat3
                     cherry feat3
import r6p2
            -----------------------rebase------->add feat1
                                                >add feat2
                                                >add feat3
                                   add feat4
                     (abandoned)                 cherry feat4


 Note that rebasing does not hurt downstreams because you're always rebasing
into a new branch, so there can't be a conflicting downstream checkout. Note
that there is no master branch with the latest and greatest - you always have to
explicitly check out a release.

 Maybe for an open source project there are other constraints that I didn't
think about. But for us, this worked.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply	[flat|nested] 10+ messages in thread
* [Buildroot] [PATCH 1/1] add sunxi-mali mainline kernel
  2017-11-11 10:03       ` Arnout Vandecappelle
@ 2017-11-13  9:07         ` Maxime Ripard
  0 siblings, 0 replies; 10+ messages in thread
From: Maxime Ripard @ 2017-11-13  9:07 UTC (permalink / raw)
  To: buildroot

Hi Arnout,

On Sat, Nov 11, 2017 at 11:03:53AM +0100, Arnout Vandecappelle wrote:
> On 09-11-17 09:05, Maxime Ripard wrote:
> > So, while I'm really not happy about the current code, I haven't found
> > better yet.
> > 
> > The idea is that we have various versions coming from ARM as
> > tarballs. On this various versions, the changes needed are the same
> > (but obviously the code to apply it on isn't), and maintaining two
> > sets of changes (through git commits or something else) would be very
> > inefficient and wouldn't scale.
> > 
> > So I went for the same set of patches that we apply on whatever
> > version is currently being built.
> 
>  But it's pretty unlikely that those patches will always apply unmodified on all
> versions, right?

It's been the case so far, so fingers crossed :)

> > Like I was saying, I'm not really
> > happy about it either so I'm definitely open to suggestions. We
> > discussed it with Thomas quite some time ago and it's the only
> > solution that stuck.
> 
> If I understand correctly, for a specific project you will always use a
> specific release (i.e. version coming from ARM), you never need to mix two
> releases, right?

Yes

>  How we solved this for a similar situation with drivers coming from the company
> I love so much is as follows. We have an "incoming" branch that just contains
> the unmodified code coming from the tarballs. Whenever a new tarball comes in,
> you check out that branch, remove everything, untar, git add -A, and commit.
> Then, for each release, a new branch is created, by rebasing the old release
> branch on top of the new release: git checkout -b r6p2 r6p0; git rebase
> incoming. And in the project configuration you check out the branch you need.
> If you create a new patch, it needs to be cherry-picked on each branch and this
> is indeed annoying. OTOH you need to separately test that new patch on each
> release anyway so it's not that much extra effort.
> 
>  So our history would look like this (time goes down, columns are branches)
> 
> incoming            r5p4           r6p0           r6p2
> import r5p4
>            -------> create
>                     add feat1
>                     add feat2
> import r6p0
>             --------rebase-------->add feat1
>                                   >add feat2
>                                    add feat3
>                      cherry feat3
> import r6p2
>             -----------------------rebase------->add feat1
>                                                 >add feat2
>                                                 >add feat3
>                                    add feat4
>                      (abandoned)                 cherry feat4
> 
> 
>  Note that rebasing does not hurt downstreams because you're always rebasing
> into a new branch, so there can't be a conflicting downstream checkout. Note
> that there is no master branch with the latest and greatest - you always have to
> explicitly check out a release.
> 
>  Maybe for an open source project there are other constraints that I didn't
> think about. But for us, this worked.

Right, so that's indeed something we talked about and I didn't like
very much because of the duplication of the efforts.

So far we've had mainly two types of changes:
  - The platform code itself that has a rather stable interface with
    the driver and is a new file, so there won't be any conflict.
  - The various fixes for the new kernel releases that so far have
    been able to apply on both, with some fuzz.

So it's not really features, it's mostly dealing with compilation
breakages, so the changes are less likely to conflict as they are
usually well isolated, and the testing effort is quite minimal too.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20171113/038891d7/attachment.asc>

^ permalink raw reply	[flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-11-13  9:07 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-05 22:19 [Buildroot] [PATCH 1/1] add sunxi-mali mainline kernel Giulio Benetti
2017-11-08 10:27 ` Maxime Ripard
2017-11-08 17:02   ` Giulio Benetti
2017-11-08 23:05   ` Arnout Vandecappelle
2017-11-08 23:15     ` Giulio Benetti
2017-11-09  8:05     ` Maxime Ripard
2017-11-09 17:00       ` Giulio Benetti
2017-11-11 10:03       ` Arnout Vandecappelle
2017-11-13  9:07         ` Maxime Ripard
2017-11-08 23:34   ` Giulio Benetti

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.