Re: svn commit: r290245 - in head/sys/contrib/vchiq/interface: vchi vchiq_arm

[John Baldwin]

On Monday, November 02, 2015 11:37:38 AM Oleksandr Tymoshenko wrote:
> 
> > On Nov 2, 2015, at 1:36 AM, Andrew Turner  wrote:
> > 
> > On Sun, 1 Nov 2015 22:17:39 + (UTC)
> > Oleksandr Tymoshenko  wrote:
> > 
> >> Author: gonzo
> >> Date: Sun Nov  1 22:17:39 2015
> >> New Revision: 290245
> >> URL: https://svnweb.freebsd.org/changeset/base/290245
> >> 
> >> Log:
> >>  Synchronize with latest upstream VCHI code:
> >> 
> >>  - Add LIB_VERSION ioctl
> >>  - Add CLOSE_DELIVERED ioctl
> >>  - Bump code version
> >> 
> >>  Upstream version: 3782f2ad42c08f4d32f64138f8be7341afc380f5
> > 
> > Was there a reason we don't use the vendor-sys area for vchiq?
> 
> What Adrian said: original code is not very portable and I have to go through 
> manual merge in my staging repo and only then merge to sys/ area 

One benefit of keeping a corresponding area in vendor-sys in sync is it
makes it easier for other folks to pick this up in the future if need be.

Noting the upstream version in each update is probably equivalent in
functionality, though it is not how we do it in the rest of the tree.

Also, Adrian, most of us do a lot of this work (FreeBSD) as volunteers.  Even
if some of us work on some of it for ${WORK} we work on other bits in our
spare time for $0 as well, so that's a lame cop out.  Part of the reason we
do this in our spare time is because it's a chance to do things "right", not
just quick hacks to satisfy a business-deadline at ${WORK} (to paraphrase
gibbs@).

-- 
John Baldwin
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r290245 - in head/sys/contrib/vchiq/interface: vchi vchiq_arm

[Adrian Chadd]

On 5 November 2015 at 10:49, John Baldwin  wrote:
> On Monday, November 02, 2015 11:37:38 AM Oleksandr Tymoshenko wrote:
>>
>> > On Nov 2, 2015, at 1:36 AM, Andrew Turner  wrote:
>> >
>> > On Sun, 1 Nov 2015 22:17:39 + (UTC)
>> > Oleksandr Tymoshenko  wrote:
>> >
>> >> Author: gonzo
>> >> Date: Sun Nov  1 22:17:39 2015
>> >> New Revision: 290245
>> >> URL: https://svnweb.freebsd.org/changeset/base/290245
>> >>
>> >> Log:
>> >>  Synchronize with latest upstream VCHI code:
>> >>
>> >>  - Add LIB_VERSION ioctl
>> >>  - Add CLOSE_DELIVERED ioctl
>> >>  - Bump code version
>> >>
>> >>  Upstream version: 3782f2ad42c08f4d32f64138f8be7341afc380f5
>> >
>> > Was there a reason we don't use the vendor-sys area for vchiq?
>>
>> What Adrian said: original code is not very portable and I have to go 
>> through manual merge in my staging repo and only then merge to sys/ area
>
> One benefit of keeping a corresponding area in vendor-sys in sync is it
> makes it easier for other folks to pick this up in the future if need be.
>
> Noting the upstream version in each update is probably equivalent in
> functionality, though it is not how we do it in the rest of the tree.
>
> Also, Adrian, most of us do a lot of this work (FreeBSD) as volunteers.  Even
> if some of us work on some of it for ${WORK} we work on other bits in our
> spare time for $0 as well, so that's a lame cop out.  Part of the reason we
> do this in our spare time is because it's a chance to do things "right", not
> just quick hacks to satisfy a business-deadline at ${WORK} (to paraphrase
> gibbs@).

Sure, but that's a case by case basis. This is definitely not the only
example of code which we don't maintain as vendor imports because of
the sheer amount of changes being done.

At some point gonzo@, I or someone may end up taking the videocore
stuff and re-porting with to minimize diffs. Same as the dri code -
it's not in vendor. Same as (IIRC) the scsi drivers; same as the intel
ethernet drivers, etc, etc. The vendor stuff seems to work fine with
userland code that requires minimal changes.

I'd love for that to change, but porting linux code doesn't always
give us that opportunity. :)



-adrian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r290245 - in head/sys/contrib/vchiq/interface: vchi vchiq_arm

[Adrian Chadd]

On 2 November 2015 at 09:18, Andriy Gapon  wrote:
> On 02/11/2015 18:13, Adrian Chadd wrote:
>> The same reason we don't use it for dri, etc.
>>
>> The vendor driver isn't portable by any stretch. We could put it
>> there, but then we'd have to maintain the vendor changes on top of it
>> in subversion and I kinda dont want to think about how that'll work
>> out.. :)
>
> Same as, say, ZFS?

Well, we're getting paid approximately $0 to try and keep this cleaner. :-)

at some point yeah, we may do it the vendor branch way.




-adrian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r290245 - in head/sys/contrib/vchiq/interface: vchi vchiq_arm

[Oleksandr Tymoshenko]

> On Nov 2, 2015, at 1:36 AM, Andrew Turner  wrote:
> 
> On Sun, 1 Nov 2015 22:17:39 + (UTC)
> Oleksandr Tymoshenko  wrote:
> 
>> Author: gonzo
>> Date: Sun Nov  1 22:17:39 2015
>> New Revision: 290245
>> URL: https://svnweb.freebsd.org/changeset/base/290245
>> 
>> Log:
>>  Synchronize with latest upstream VCHI code:
>> 
>>  - Add LIB_VERSION ioctl
>>  - Add CLOSE_DELIVERED ioctl
>>  - Bump code version
>> 
>>  Upstream version: 3782f2ad42c08f4d32f64138f8be7341afc380f5
> 
> Was there a reason we don't use the vendor-sys area for vchiq?

What Adrian said: original code is not very portable and I have to go through 
manual merge in my staging repo and only then merge to sys/ area 

___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r290245 - in head/sys/contrib/vchiq/interface: vchi vchiq_arm

[Adrian Chadd]

The same reason we don't use it for dri, etc.

The vendor driver isn't portable by any stretch. We could put it
there, but then we'd have to maintain the vendor changes on top of it
in subversion and I kinda dont want to think about how that'll work
out.. :)




-adrian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r290245 - in head/sys/contrib/vchiq/interface: vchi vchiq_arm

[Andriy Gapon]

On 02/11/2015 18:13, Adrian Chadd wrote:
> The same reason we don't use it for dri, etc.
> 
> The vendor driver isn't portable by any stretch. We could put it
> there, but then we'd have to maintain the vendor changes on top of it
> in subversion and I kinda dont want to think about how that'll work
> out.. :)

Same as, say, ZFS?


-- 
Andriy Gapon
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Re: svn commit: r290245 - in head/sys/contrib/vchiq/interface: vchi vchiq_arm

[Andrew Turner]

On Sun, 1 Nov 2015 22:17:39 + (UTC)
Oleksandr Tymoshenko  wrote:

> Author: gonzo
> Date: Sun Nov  1 22:17:39 2015
> New Revision: 290245
> URL: https://svnweb.freebsd.org/changeset/base/290245
> 
> Log:
>   Synchronize with latest upstream VCHI code:
>   
>   - Add LIB_VERSION ioctl
>   - Add CLOSE_DELIVERED ioctl
>   - Bump code version
>   
>   Upstream version: 3782f2ad42c08f4d32f64138f8be7341afc380f5

Was there a reason we don't use the vendor-sys area for vchiq?

Andrew
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

svn commit: r290245 - in head/sys/contrib/vchiq/interface: vchi vchiq_arm

[Oleksandr Tymoshenko]

Author: gonzo
Date: Sun Nov  1 22:17:39 2015
New Revision: 290245
URL: https://svnweb.freebsd.org/changeset/base/290245

Log:
  Synchronize with latest upstream VCHI code:
  
  - Add LIB_VERSION ioctl
  - Add CLOSE_DELIVERED ioctl
  - Bump code version
  
  Upstream version: 3782f2ad42c08f4d32f64138f8be7341afc380f5

Added:
  head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_debugfs.c   (contents, props 
changed)
  head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_debugfs.h   (contents, props 
changed)
  head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_killable.h   (contents, 
props changed)
Deleted:
  head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_proc.c
Modified:
  head/sys/contrib/vchiq/interface/vchi/vchi.h
  head/sys/contrib/vchiq/interface/vchi/vchi_common.h
  head/sys/contrib/vchiq/interface/vchiq_arm/vchiq.h
  head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_2835_arm.c
  head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_arm.c
  head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_arm.h
  head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_cfg.h
  head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_connected.c
  head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_connected.h
  head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_core.c
  head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_core.h
  head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_if.h
  head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_ioctl.h
  head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_kern_lib.c
  head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_shim.c
  head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_util.c
  head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_util.h

Modified: head/sys/contrib/vchiq/interface/vchi/vchi.h
==
--- head/sys/contrib/vchiq/interface/vchi/vchi.hSun Nov  1 22:07:40 
2015(r290244)
+++ head/sys/contrib/vchiq/interface/vchi/vchi.hSun Nov  1 22:17:39 
2015(r290245)
@@ -220,7 +220,12 @@ extern int32_t vchi_service_use( const V
 // Routine to decrement ref count on a named service
 extern int32_t vchi_service_release( const VCHI_SERVICE_HANDLE_T handle );
 
-// Routine to send a message accross a service
+// Routine to set a control option for a named service
+extern int32_t vchi_service_set_option( const VCHI_SERVICE_HANDLE_T handle,
+   VCHI_SERVICE_OPTION_T option,
+   int value);
+
+// Routine to send a message across a service
 extern int32_t vchi_msg_queue( VCHI_SERVICE_HANDLE_T handle,
const void *data,
uint32_t data_size,

Modified: head/sys/contrib/vchiq/interface/vchi/vchi_common.h
==
--- head/sys/contrib/vchiq/interface/vchi/vchi_common.h Sun Nov  1 22:07:40 
2015(r290244)
+++ head/sys/contrib/vchiq/interface/vchi/vchi_common.h Sun Nov  1 22:17:39 
2015(r290245)
@@ -110,7 +110,19 @@ typedef enum
VCHI_CALLBACK_REASON_MAX
 } VCHI_CALLBACK_REASON_T;
 
-//Calback used by all services / bulk transfers
+// service control options
+typedef enum
+{
+   VCHI_SERVICE_OPTION_MIN,
+
+   VCHI_SERVICE_OPTION_TRACE,
+   VCHI_SERVICE_OPTION_SYNCHRONOUS,
+
+   VCHI_SERVICE_OPTION_MAX
+} VCHI_SERVICE_OPTION_T;
+
+
+//Callback used by all services / bulk transfers
 typedef void (*VCHI_CALLBACK_T)( void *callback_param, //my service local param
  VCHI_CALLBACK_REASON_T reason,
  void *handle ); //for transmitting msg's only

Modified: head/sys/contrib/vchiq/interface/vchiq_arm/vchiq.h
==
--- head/sys/contrib/vchiq/interface/vchiq_arm/vchiq.h  Sun Nov  1 22:07:40 
2015(r290244)
+++ head/sys/contrib/vchiq/interface/vchiq_arm/vchiq.h  Sun Nov  1 22:17:39 
2015(r290245)
@@ -38,4 +38,3 @@
 #include "vchiq_util.h"
 
 #endif
-

Modified: head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_2835_arm.c
==
--- head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_2835_arm.c Sun Nov  1 
22:07:40 2015(r290244)
+++ head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_2835_arm.c Sun Nov  1 
22:17:39 2015(r290245)
@@ -61,6 +61,7 @@ MALLOC_DEFINE(M_VCPAGELIST, "vcpagelist"
 #include "vchiq_arm.h"
 #include "vchiq_2835.h"
 #include "vchiq_connected.h"
+#include "vchiq_killable.h"
 
 #define MAX_FRAGMENTS (VCHIQ_NUM_CURRENT_BULKS * 2)
 

Modified: head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_arm.c
==
--- head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_arm.c  Sun Nov  1 
22:07:40 2015(r290244)
+++ head/sys/contrib/vchiq/interface/vchiq_arm/vchiq_arm.c  Sun Nov  1 
22:17:39 2015(r290245)