Re: video(1) and modesetting driver

2019-02-14 Thread Raphael Graf
On Wed, Feb 13, 2019 at 04:09:10PM -0200, Martin Pieuchot wrote:
> On 07/02/19(Thu) 13:52, Raphael Graf wrote:
> > [...] 
> > The new diff below solves this yuy2/yuyv problem by defining them both under
> > the same name 'yuy2'.
> 
> That's great.  I would just change the comment to explain that it's due
> to an incoherency between the names reported by XvListImageFormats(3) and
> V4L2 :) 

I'll do this when the general idea of the diff gets accepted..

> 
> > The only change to the manpage is now the addition of yv12 to the list of
> > valid encodings.
> 
> Fine, I just missed the point: why do we need to support yv12?

The support for yv12 as an input encoding is actually a side effect of the
implementation. Webcams (video(4)) do not provide yv12, but is now possible to
read and display yv12 encoded files.

> 
> > The trickiest part is the 'choose_enc' function where encodings are chosen
> > based on device capabilities.
> > The following conversions are now possible:
> > yuy2 -> uyvy
> > yuy2 -> yv12
> > uyvy -> yuy2
> > uyvy -> yv12
> > 
> > As my webcam only provides yuy2, I have used input-files for testing:
> > $ video -i test.yuy2
> > $ video -i test.uyvy -e uyvy
> > $ video -i test.yv12 -e yv12
> > 
> > These examples work for me with both drivers (modesetting and intel).
> > The conversion to yv12 has a small performance impact, of course. Do you 
> > think
> > the performance is acceptable?
> 
> Do you think it is?  When is the conversion needed?
>

Conversion to yv12 is needed when Xv does neither support yuy2 nor uyvy.
This is the case when the modesetting driver is in use (see output of xvinfo).
I think the performance is acceptable, it is hardly noticable on my laptops.
 



Re: video(1) and modesetting driver

2019-02-07 Thread Raphael Graf
On Fri, Jan 25, 2019 at 09:09:29AM -0200, Martin Pieuchot wrote:
> On 25/01/19(Fri) 11:16, Raphael Graf wrote:
> > On Wed, Jan 23, 2019 at 12:54:51PM -0200, Martin Pieuchot wrote:
> > > > Index: video.c
> > > > ===
> > > > RCS file: /cvs/xenocara/app/video/video.c,v
> > > > retrieving revision 1.26
> > > > diff -u -p -u -p -r1.26 video.c
> > > > --- video.c 4 Jan 2019 17:45:00 -   1.26
> > > > +++ video.c 16 Jan 2019 11:30:21 -
> > > > @@ -38,6 +38,8 @@
> > > >  #include 
> > > >  #include 
> > > > 
> > > > +#define V_V4L2_PIX_FMT_YUY2v4l2_fourcc('Y', 'U', 'Y', '2')
> > > 
> > > Why do we need this define and not the others?  Aren't we missing an
> > > include?
> > 
> > Actually, I don't know why this define is missing in videoio.h.
> > This YUY2 format (id:0x32595559) is reported by Xv.
> > The uvideo(4) driver reports YUYV which has a define in videoio.h.
> > (YUY2 and YUYV are equivalent)
> 
> I see.  I believe you're being too clever her.  XvListImageFormats(3)
> returns you a list with an Id in FourCC format and you're using V4L2
> defines to match these IDs.
> 
> I'd suggest you define only one encoding "yuy2" or "yuyv" and make the
> matching function, find_enc_by_id() a bit more clever.  That would
> explicitly document that Xv and V4L2 use different names for the same
> format.  On top of that you'll get rid of your conversion code :)
>  

The new diff below solves this yuy2/yuyv problem by defining them both under
the same name 'yuy2'.
The only change to the manpage is now the addition of yv12 to the list of
valid encodings.

The trickiest part is the 'choose_enc' function where encodings are chosen
based on device capabilities.
The following conversions are now possible:
yuy2 -> uyvy
yuy2 -> yv12
uyvy -> yuy2
uyvy -> yv12

As my webcam only provides yuy2, I have used input-files for testing:
$ video -i test.yuy2
$ video -i test.uyvy -e uyvy
$ video -i test.yv12 -e yv12

These examples work for me with both drivers (modesetting and intel).
The conversion to yv12 has a small performance impact, of course. Do you think
the performance is acceptable?

> > In the new diff, I have changed the variable names enc_in/enc_out to 
> > enc/enc_xv
> > as the second 'enc' is only used for Xv output.
> > I also fixed the style(9) issues and added a CONV_NONE define.
> 
> I find enc_in/enc_out more explicit, but let's keep it like that for
> now.  This also makes the diff smaller :)
> 
> > Note that I'm not sure if the algorithm used in the yuy2_to_yv12 function is
> > correct in respect to color theory..
> > (It is a conversion from 16 to 12 bits/pixel)
> 
> I'm sure you can find some good documentation and/or example about that
> on the Web or in the existing freesoftware ecosystem.
> 

Yes, there are libraries like 'libyuv' doing it in the same way.
(they also have optimized versions (SSE etc.))

Any comments, questions or feedback?



Index: video.1
===
RCS file: /cvs/xenocara/app/video/video.1,v
retrieving revision 1.13
diff -u -p -u -p -r1.13 video.1
--- video.1 4 Jun 2016 07:44:32 -   1.13
+++ video.1 7 Feb 2019 12:08:37 -
@@ -84,9 +84,10 @@ The default is 0, the first adaptor repo
 .It Fl e Ar encoding
 Lowercase FOURCC name of video encoding to use.
 Valid arguments are
-.Ql uyvy
+.Ql uyvy ,
+.Ql yuy2
 and
-.Ql yuy2 .
+.Ql yv12 .
 The default is
 .Ql yuy2
 unless
Index: video.c
===
RCS file: /cvs/xenocara/app/video/video.c,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 video.c
--- video.c 22 Jan 2019 20:02:40 -  1.27
+++ video.c 7 Feb 2019 12:08:37 -
@@ -38,6 +38,9 @@
 #include 
 #include 
 
+/* Synonym for YUYV */
+#define V_V4L2_PIX_FMT_YUY2v4l2_fourcc('Y', 'U', 'Y', '2')
+
 /* Xv(3) adaptor properties */
 struct xv_adap {
char name[128];
@@ -133,20 +136,22 @@ struct dev {
 /* video encodingss */
 struct encodings {
char*name;
+   int  id;
int  bpp;
-   int  xv_id;
-   int  dev_id;
-#defineSW_DEV  0x1
-#defineSW_XV   0x2
-#define SW_MASK(SW_DEV | SW_XV)
+#defineSUP_DEV 0x1
+#defineSUP_XV  0x2
int  flags;
 } encs[] = {
+#define ENC_YUYV   1
+   { "yuy2", V4L2_PIX_FMT_YUYV, 16, 0 },
 #define ENC_YUY2   0
-   { "yuy2", 16, -1, -1, 0 },
-#define ENC_UYVY   1
-   { "uyvy", 16, -1, -1, 0 },
-#define ENC_LAST   2
-   { NULL, 0, 0, 0,

Re: pckbc(4) diff

2019-01-29 Thread Raphael Graf
On Mon, Jan 28, 2019 at 08:14:09PM +0100, Marcus Glocker wrote:
> On some machines when the pckbc(4) keyboard controller driver attaches
> to the console, it's possible to inject characters by moving your mouse
> in to the keyboard channel.  When injecting enough noise the keyboard
> will stop operating at some point.  A nice way to test this, e.g. on my
> ThinkPad, is by entering in to UKC at boot time and then move your
> mouse.
> 
> This diff will discard characters coming from the aux slot which are
> mixed in to the keyboard slot when we're still in console mode.
> 
> This issue has been reported by deraadt@ who already has OK'ed the diff.
> 
> Comments?  Testing?  More OKs?

I can confirm this fixes the issue on a lenovo X1 Carbon. 

> 
> Thanks,
> Marcus
> 
> 
> Index: sys/dev/ic/pckbc.c
> ===
> RCS file: /cvs/src/sys/dev/ic/pckbc.c,v
> retrieving revision 1.50
> diff -u -p -u -p -r1.50 pckbc.c
> --- sys/dev/ic/pckbc.c11 Mar 2017 11:55:03 -  1.50
> +++ sys/dev/ic/pckbc.c27 Jan 2019 09:01:31 -
> @@ -161,6 +161,9 @@ pckbc_poll_data1(bus_space_tag_t iot, bu
>   if (slot == PCKBC_AUX_SLOT) {
>   DPRINTF("lost kbd 0x%x\n", c);
>   continue;
> + } else if (stat & KBS_AUXDATA) {
> + DPRINTF("discard aux data 0x%x\n", c);
> + continue;
>   }
>   }
>   return (c);
> 



Re: video(1) and modesetting driver

2019-01-25 Thread Raphael Graf
On Fri, Jan 25, 2019 at 12:52:38PM +0200, Artturi Alm wrote:
> On Fri, Jan 25, 2019 at 11:16:49AM +0100, Raphael Graf wrote:
> > Hi Martin, 
> > Thanks for your feedback!
> > 
> > On Wed, Jan 23, 2019 at 12:54:51PM -0200, Martin Pieuchot wrote:
> > > Hello Raphael,
> > > 
> > > On 16/01/19(Wed) 12:41, Raphael Graf wrote:
> > > > Here is an attempt to make video(1) work with the modesetting driver.
> > > > See https://marc.info/?l=openbsd-bugs=152231686416039=2
> > > > 
> > > > The general idea:
> > > > If there is no common encoding for input (device) and output (Xv), the
> > > > encoding is converted to something supported by the output.
> > > > No conversion is done if the output is sent to file (options -o/-O).
> > > > 
> > > > The option -e is now used as the input format. The output format
> > > > is selected automatically (if output goes to Xv).
> > > > 
> > > > The following encodings are supported: yuy2, yuyv, uyuy, yv12
> > > 
> > > Did you test all of them?
> > 
> > Yes, I have tested all encodings with these two devices:
> > 
> > uvideo0 at uhub0 port 6 configuration 1 interface 0
> > "Chicony Electronics Co., Ltd. product 0x480c" rev 2.00/31.34 addr 2
> > 
> > uvideo0 at uhub1 port 8 configuration 1 interface 0 "SC20A38485AA4629RX
> > Integrated Camera" rev 2.00/0.21 addr 4
> > 
> > > 
> > > > yuy2 and yuyv are treated as two different encodings, they share the 
> > > > same
> > > > pixelformat, but have different ids. (This behaviour is different from 
> > > > the
> > > > current description of '-e' in the manpage)
> > > 
> > > What about fixing the manpage then? ;)
> > 
> > The new diff below contains the changes to the manpage.
> > 
> > > 
> > > > I have tested on two lenovo laptops using both drivers (modesetting and 
> > > > intel).
> > > > 
> > > > On my laptop (lenovo X1 Carbon), with modesetting diver:
> > > > yuyv is converted to yv12 before sending to Xv.
> > > > 
> > > > On the same laptop With intel driver:
> > > > yuyv is converted to yuy2 (no-op)
> > > 
> > > Nice work, some comments below.
> > > 
> > > Make sure the code you're writing follows style(9) :o)
> > > 
> > > > Index: video.c
> > > > ===
> > > > RCS file: /cvs/xenocara/app/video/video.c,v
> > > > retrieving revision 1.26
> > > > diff -u -p -u -p -r1.26 video.c
> > > > --- video.c 4 Jan 2019 17:45:00 -   1.26
> > > > +++ video.c 16 Jan 2019 11:30:21 -
> > > > @@ -38,6 +38,8 @@
> > > >  #include 
> > > >  #include 
> > > > 
> > > > +#define V_V4L2_PIX_FMT_YUY2v4l2_fourcc('Y', 'U', 'Y', '2')
> > > 
> > > Why do we need this define and not the others?  Aren't we missing an
> > > include?
> > 
> > Actually, I don't know why this define is missing in videoio.h.
> > This YUY2 format (id:0x32595559) is reported by Xv.
> > The uvideo(4) driver reports YUYV which has a define in videoio.h.
> > (YUY2 and YUYV are equivalent)
> > 
> > In the new diff, I have changed the variable names enc_in/enc_out to 
> > enc/enc_xv
> > as the second 'enc' is only used for Xv output.
> > I also fixed the style(9) issues and added a CONV_NONE define.
> > 
> > Note that I'm not sure if the algorithm used in the yuy2_to_yv12 function is
> > correct in respect to color theory..
> > (It is a conversion from 16 to 12 bits/pixel)
> > 
> > Sorry, it is still a big diff, feedback is welcome.
> > 
> > 
> 
> Hi,
> 
> got one question below.
> 
> -Artturi
> 
> [...snip...]
> 
> > @@ -1633,6 +1631,34 @@ got_shutdown(int s)
> >  }
> >  
> >  int
> > +yuy2_to_yv12(uint8_t *src, uint8_t *dst, int width, int height)
> > +{
> > +   int row, col, c, o;
> > +   int iy = 0;
> > +   int iu = width * height;
> > +   int iv = iu + iu / 4;
> > +
> > +   for (row = 0; row < height * 2; row += 2) {
> > +   c = row * width;
> > +   for (col = 0; col < width * 2 ; col += 4) {
> > +   o = c + col;
> > +   dst[iy++] = src[o];
> > +   dst[iy++] = src[o + 2];
> > +   if ((row & 0x03)  == 0) {
> > +   o++;
> > +   dst[iv++] = (src[o] + src[o + width * 2]) / 2;
> > +   o += 2;
> > +   dst[iu++] = (src[o] + src[o + width * 2]) / 2;
> > +   if (o + width * 2 >= iu*2)
> > +   printf("hello\n");
> 
> is that a placeholder for something relevant, or what does hello mean here?

Oups, sorry, can you ignore that for now? I'll remove this in the next 
iteration.

> 
> > +   }
> > +   }
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +int
> >  stream(struct video *vid)
> >  {
> > struct xdsp *x = >xdsp;
> 
> [...snip...]



Re: video(1) and modesetting driver

2019-01-25 Thread Raphael Graf
On Fri, Jan 25, 2019 at 09:09:29AM -0200, Martin Pieuchot wrote:
> On 25/01/19(Fri) 11:16, Raphael Graf wrote:
> > On Wed, Jan 23, 2019 at 12:54:51PM -0200, Martin Pieuchot wrote:
> > > > Index: video.c
> > > > ===
> > > > RCS file: /cvs/xenocara/app/video/video.c,v
> > > > retrieving revision 1.26
> > > > diff -u -p -u -p -r1.26 video.c
> > > > --- video.c 4 Jan 2019 17:45:00 -   1.26
> > > > +++ video.c 16 Jan 2019 11:30:21 -
> > > > @@ -38,6 +38,8 @@
> > > >  #include 
> > > >  #include 
> > > > 
> > > > +#define V_V4L2_PIX_FMT_YUY2v4l2_fourcc('Y', 'U', 'Y', '2')
> > > 
> > > Why do we need this define and not the others?  Aren't we missing an
> > > include?
> > 
> > Actually, I don't know why this define is missing in videoio.h.
> > This YUY2 format (id:0x32595559) is reported by Xv.
> > The uvideo(4) driver reports YUYV which has a define in videoio.h.
> > (YUY2 and YUYV are equivalent)
> 
> I see.  I believe you're being too clever her.  XvListImageFormats(3)
> returns you a list with an Id in FourCC format and you're using V4L2
> defines to match these IDs.
> 
> I'd suggest you define only one encoding "yuy2" or "yuyv" and make the
> matching function, find_enc_by_id() a bit more clever.  That would
> explicitly document that Xv and V4L2 use different names for the same
> format.  On top of that you'll get rid of your conversion code :)
>  

I actually tried to do this, but it's not trivial.
The current code had only one entry for yuy2/yuyv in 'encs[]' and handled the
situation by having xv_id and dev_id in 'struct encodings':

struct encodings {
char*name;
int  bpp;
int  xv_id;
int  dev_id;
int  flags;
}  

But this approach does not work when 'bpp' changes for the output.
There is also the case of '-O' where output goes to 'Xv' and 'file'
simultanously, using different encodings for the two outputs.
When using the modesetting driver, Xv output needs yv12, and the file is
written in yuy2.

(It would be possible to add xv_bpp and dev_bpp to 'struct encodings', but this
would be a bit hacky, I think)

> > In the new diff, I have changed the variable names enc_in/enc_out to 
> > enc/enc_xv
> > as the second 'enc' is only used for Xv output.
> > I also fixed the style(9) issues and added a CONV_NONE define.
> 
> I find enc_in/enc_out more explicit, but let's keep it like that for
> now.  This also makes the diff smaller :)
> 
> > Note that I'm not sure if the algorithm used in the yuy2_to_yv12 function is
> > correct in respect to color theory..
> > (It is a conversion from 16 to 12 bits/pixel)
> 
> I'm sure you can find some good documentation and/or example about that
> on the Web or in the existing freesoftware ecosystem.

I'll do some more research on this topic.

> 
> > Index: video.1
> > ===
> > RCS file: /cvs/xenocara/app/video/video.1,v
> > retrieving revision 1.13
> > diff -u -p -u -p -r1.13 video.1
> > --- video.1 4 Jun 2016 07:44:32 -   1.13
> > +++ video.1 25 Jan 2019 09:51:12 -
> > @@ -84,18 +84,19 @@ The default is 0, the first adaptor repo
> >  .It Fl e Ar encoding
> >  Lowercase FOURCC name of video encoding to use.
> >  Valid arguments are
> > +.Ql yuyv ,
> > +.Ql yuy2 ,
> >  .Ql uyvy
> >  and
> > -.Ql yuy2 .
> > +.Ql yv12 .
> >  The default is
> > -.Ql yuy2
> > -unless
> > -.Ar file
> > -is being used and only supports
> > -.Ql uyvy ,
> > -in which case
> > -.Ql uyvy
> > -will be used by default.
> > +.Ql yuyv .
> > +If reading from a
> > +.Xr video 4
> > +device and
> > +.Ql yuyv
> > +is not supported, the default is
> > +.Ql uyvy .
> >  .It Fl f Ar file
> >  .Xr video 4
> >  device from which frames will be read.
> > @@ -338,6 +339,6 @@ Note that with the first three commands,
> >  does not support 640x480 pixels sized frames, the largest frame size
> >  smaller than 640x480 will be used, and if
> >  .Ar /dev/video
> > -does not support yuy2 encoding, uyvy will be used.
> > +does not support yuyv encoding, uyvy will be used.
> >  .Sh SEE ALSO
> >  .Xr video 4
> > Index: video.c
> > ===
> > RCS file: /cvs/xenocara/app/video/video.c,v
> > retrieving revision 1.27
> > diff -u -p -u -p

Re: video(1) and modesetting driver

2019-01-25 Thread Raphael Graf
Hi Martin, 
Thanks for your feedback!

On Wed, Jan 23, 2019 at 12:54:51PM -0200, Martin Pieuchot wrote:
> Hello Raphael,
> 
> On 16/01/19(Wed) 12:41, Raphael Graf wrote:
> > Here is an attempt to make video(1) work with the modesetting driver.
> > See https://marc.info/?l=openbsd-bugs=152231686416039=2
> > 
> > The general idea:
> > If there is no common encoding for input (device) and output (Xv), the
> > encoding is converted to something supported by the output.
> > No conversion is done if the output is sent to file (options -o/-O).
> > 
> > The option -e is now used as the input format. The output format
> > is selected automatically (if output goes to Xv).
> > 
> > The following encodings are supported: yuy2, yuyv, uyuy, yv12
> 
> Did you test all of them?

Yes, I have tested all encodings with these two devices:

uvideo0 at uhub0 port 6 configuration 1 interface 0
"Chicony Electronics Co., Ltd. product 0x480c" rev 2.00/31.34 addr 2

uvideo0 at uhub1 port 8 configuration 1 interface 0 "SC20A38485AA4629RX
Integrated Camera" rev 2.00/0.21 addr 4

> 
> > yuy2 and yuyv are treated as two different encodings, they share the same
> > pixelformat, but have different ids. (This behaviour is different from the
> > current description of '-e' in the manpage)
> 
> What about fixing the manpage then? ;)

The new diff below contains the changes to the manpage.

> 
> > I have tested on two lenovo laptops using both drivers (modesetting and 
> > intel).
> > 
> > On my laptop (lenovo X1 Carbon), with modesetting diver:
> > yuyv is converted to yv12 before sending to Xv.
> > 
> > On the same laptop With intel driver:
> > yuyv is converted to yuy2 (no-op)
> 
> Nice work, some comments below.
> 
> Make sure the code you're writing follows style(9) :o)
> 
> > Index: video.c
> > ===
> > RCS file: /cvs/xenocara/app/video/video.c,v
> > retrieving revision 1.26
> > diff -u -p -u -p -r1.26 video.c
> > --- video.c 4 Jan 2019 17:45:00 -   1.26
> > +++ video.c 16 Jan 2019 11:30:21 -
> > @@ -38,6 +38,8 @@
> >  #include 
> >  #include 
> > 
> > +#define V_V4L2_PIX_FMT_YUY2v4l2_fourcc('Y', 'U', 'Y', '2')
> 
> Why do we need this define and not the others?  Aren't we missing an
> include?

Actually, I don't know why this define is missing in videoio.h.
This YUY2 format (id:0x32595559) is reported by Xv.
The uvideo(4) driver reports YUYV which has a define in videoio.h.
(YUY2 and YUYV are equivalent)

In the new diff, I have changed the variable names enc_in/enc_out to enc/enc_xv
as the second 'enc' is only used for Xv output.
I also fixed the style(9) issues and added a CONV_NONE define.

Note that I'm not sure if the algorithm used in the yuy2_to_yv12 function is
correct in respect to color theory..
(It is a conversion from 16 to 12 bits/pixel)

Sorry, it is still a big diff, feedback is welcome.



Index: video.1
===
RCS file: /cvs/xenocara/app/video/video.1,v
retrieving revision 1.13
diff -u -p -u -p -r1.13 video.1
--- video.1 4 Jun 2016 07:44:32 -   1.13
+++ video.1 25 Jan 2019 09:51:12 -
@@ -84,18 +84,19 @@ The default is 0, the first adaptor repo
 .It Fl e Ar encoding
 Lowercase FOURCC name of video encoding to use.
 Valid arguments are
+.Ql yuyv ,
+.Ql yuy2 ,
 .Ql uyvy
 and
-.Ql yuy2 .
+.Ql yv12 .
 The default is
-.Ql yuy2
-unless
-.Ar file
-is being used and only supports
-.Ql uyvy ,
-in which case
-.Ql uyvy
-will be used by default.
+.Ql yuyv .
+If reading from a
+.Xr video 4
+device and
+.Ql yuyv
+is not supported, the default is
+.Ql uyvy .
 .It Fl f Ar file
 .Xr video 4
 device from which frames will be read.
@@ -338,6 +339,6 @@ Note that with the first three commands,
 does not support 640x480 pixels sized frames, the largest frame size
 smaller than 640x480 will be used, and if
 .Ar /dev/video
-does not support yuy2 encoding, uyvy will be used.
+does not support yuyv encoding, uyvy will be used.
 .Sh SEE ALSO
 .Xr video 4
Index: video.c
===
RCS file: /cvs/xenocara/app/video/video.c,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 video.c
--- video.c 22 Jan 2019 20:02:40 -  1.27
+++ video.c 25 Jan 2019 09:51:12 -
@@ -38,6 +38,8 @@
 #include 
 #include 
 
+#define V_V4L2_PIX_FMT_YUY2v4l2_fourcc('Y', 'U', 'Y', '2')
+
 /* Xv(3) adaptor properties */
 struct xv_adap {
char name[128];
@@ -133,20 +135,23 @@ struct dev {
 /* video encodingss */
 struct encodings {
char*name;
+   int  id;
int  bpp;
-   int  xv_id;
-   int  dev_id;
 

video(1) and modesetting driver

2019-01-16 Thread Raphael Graf
Here is an attempt to make video(1) work with the modesetting driver.
See https://marc.info/?l=openbsd-bugs=152231686416039=2

The general idea:
If there is no common encoding for input (device) and output (Xv), the
encoding is converted to something supported by the output.
No conversion is done if the output is sent to file (options -o/-O).

The option -e is now used as the input format. The output format
is selected automatically (if output goes to Xv).

The following encodings are supported: yuy2, yuyv, uyuy, yv12

yuy2 and yuyv are treated as two different encodings, they share the same
pixelformat, but have different ids. (This behaviour is different from the
current description of '-e' in the manpage)


I have tested on two lenovo laptops using both drivers (modesetting and intel).

On my laptop (lenovo X1 Carbon), with modesetting diver:
yuyv is converted to yv12 before sending to Xv.

On the same laptop With intel driver:
yuyv is converted to yuy2 (no-op)




Index: video.c
===
RCS file: /cvs/xenocara/app/video/video.c,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 video.c
--- video.c 4 Jan 2019 17:45:00 -   1.26
+++ video.c 16 Jan 2019 11:30:21 -
@@ -38,6 +38,8 @@
 #include 
 #include 

+#define V_V4L2_PIX_FMT_YUY2v4l2_fourcc('Y', 'U', 'Y', '2')
+
 /* Xv(3) adaptor properties */
 struct xv_adap {
char name[128];
@@ -133,20 +135,23 @@ struct dev {
 /* video encodingss */
 struct encodings {
char*name;
+   int  id;
int  bpp;
-   int  xv_id;
-   int  dev_id;
 #defineSW_DEV  0x1
 #defineSW_XV   0x2
 #define SW_MASK(SW_DEV | SW_XV)
int  flags;
 } encs[] = {
 #define ENC_YUY2   0
-   { "yuy2", 16, -1, -1, 0 },
-#define ENC_UYVY   1
-   { "uyvy", 16, -1, -1, 0 },
-#define ENC_LAST   2
-   { NULL, 0, 0, 0, 0 }
+   { "yuy2", V_V4L2_PIX_FMT_YUY2, 16, 0 },
+#define ENC_YUYV   1
+   { "yuyv", V4L2_PIX_FMT_YUYV, 16, 0 },
+#define ENC_UYVY   2
+   { "uyvy", V4L2_PIX_FMT_UYVY,  16, 0 },
+#define ENC_YV12   3
+   { "yv12", V4L2_PIX_FMT_YVU420, 12, 0 },
+#define ENC_LAST   4
+   { NULL, 0, 0, 0 }
 };

 struct video {
@@ -163,8 +168,10 @@ struct video {
int  iofile_fd;
char*sz_str;
 #defineCONV_SWAP   0x1
+#defineCONV_YV12   0x2
int  conv_type;
-   int  enc;
+   int  enc_in;
+   int  enc_out;
int  full_screen;
int  net_wm;
int  width;
@@ -216,6 +223,7 @@ int stream(struct video *);
 void got_frame(int);
 void got_shutdown(int);
 int find_enc(char *);
+int find_by_id(int);
 void usage(void);

 static volatile sig_atomic_t play, shutdown, hold, wout;
@@ -242,6 +250,17 @@ find_enc(char *name)
 }

 int
+find_enc_by_id(int id)
+{
+   int i;
+
+   for (i = 0; i < ENC_LAST; i++)
+   if (encs[i].id == id)
+   break;
+   return i;
+}
+
+int
 xv_get_info(struct video *vid)
 {
struct xdsp *x = >xdsp;
@@ -251,7 +270,6 @@ xv_get_info(struct video *vid)
struct xv_adap *adap;
unsigned int nenc, p;
int num_xvformats, nadaps, i, j, ret;
-   char fmtName[5];

if ((x->dpy = XOpenDisplay(NULL)) == NULL) {
warnx("cannot open display %s", XDisplayName(NULL));
@@ -312,16 +330,9 @@ xv_get_info(struct video *vid)
_xvformats);
adap->nfmts = 0;
for (j = 0; j < num_xvformats; j++) {
-   snprintf(fmtName, sizeof(fmtName), "%c%c%c%c",
-   xvformats[j].id & 0xff,
-   (xvformats[j].id >> 8) & 0xff,
-   (xvformats[j].id >> 16) & 0xff,
-   (xvformats[j].id >> 24) & 0xff);
-   if (!strcmp(fmtName, "YUY2")) {
-   encs[ENC_YUY2].xv_id = xvformats[j].id;
-   adap->fmts[adap->nfmts++] = xvformats[j].id;
-   } else if (!strcmp(fmtName, "UYVY")) {
-   encs[ENC_UYVY].xv_id = xvformats[j].id;
+   int enc = find_enc_by_id(xvformats[j].id);
+   if (enc < ENC_LAST) {
+   encs[enc].flags |= SW_XV;
adap->fmts[adap->nfmts++] = xvformats[j].id;
}
if (adap->nfmts >= MAX_FMTS)
@@ -369,20 +380,20 @@ xv_sel_adap(struct video *vid)
x->cur_adap = i;
adap = >adaps[i];
for (i = 0; i < adap->nfmts; i++) {
-   if (adap->fmts[i] == encs[vid->enc].xv_id)
+   if (adap->fmts[i] == encs[vid->enc_out].id)
  

mandoc -T html -O toc, nested anchor tags

2018-12-22 Thread Raphael Graf
The html output contains nested anchor tags if the TABLE OF CONTENTS
has a second level.
For example, see http://man.openbsd.org/mdoc

The diff closes the anchor tag before printing the 'ul' of the second level.


Index: mdoc_html.c
===
RCS file: /cvs/src/usr.bin/mandoc/mdoc_html.c,v
retrieving revision 1.193
diff -u -p -u -p -r1.193 mdoc_html.c
--- mdoc_html.c 15 Dec 2018 23:33:20 -  1.193
+++ mdoc_html.c 22 Dec 2018 14:26:09 -
@@ -507,7 +507,7 @@ static int
 mdoc_sh_pre(MDOC_ARGS)
 {
struct roff_node*sn, *subn;
-   struct tag  *t, *tsec, *tsub;
+   struct tag  *t, *ta, *tsec, *tsub;
char*id;
int  sc;

@@ -532,7 +532,7 @@ mdoc_sh_pre(MDOC_ARGS)
for (sn = n; sn != NULL; sn = sn->next) {
tsec = print_otag(h, TAG_LI, "");
id = html_make_id(sn->head, 0);
-   print_otag(h, TAG_A, "hR", id);
+   ta = print_otag(h, TAG_A, "hR", id);
free(id);
print_mdoc_nodelist(meta, sn->head->child, h);
tsub = NULL;
@@ -543,9 +543,11 @@ mdoc_sh_pre(MDOC_ARGS)
id = html_make_id(subn->head, 0);
if (id == NULL)
continue;
-   if (tsub == NULL)
+   if (tsub == NULL) {
+   print_tagq(h, ta);
print_otag(h, TAG_UL,
"c", "Bl-compact");
+   }
tsub = print_otag(h, TAG_LI, "");
print_otag(h, TAG_A, "hR", id);
free(id);




Re: mandoc -T html default style

2018-12-21 Thread Raphael Graf
Hi Ingo,

On Thu, December 20, 2018 11:53 pm, Ingo Schwarze wrote:
> Hi Ted, hi Raphael,
>
> Ted Unangst wrote on Thu, Dec 20, 2018 at 11:36:06AM -0500:
>> Raphael Graf wrote:
>
>>> The diff inserts some space above the footer.
>>> This improves readability and makes it similar to the other output formats.
>>>
>>> Here is an example found in the wild, demonstrating the problem:
>>> https://webassembly.github.io/wabt/doc/wasm-objdump.1.html
>
> How did that page get generated?  By some Github automatic or
> half-automatic infrastructure, and if so, how exactly?  Or did the
> maintainers of "webassembly" simply generate that file by hand?
> Also, is that URI linked to from anywhere?  It tried clicking around
> the "webassembly" website, but failed to find any link to the URI
> you cite.

I guess the html-pages where generated and copied to the server by hand.
It is the result of this pull request:
https://github.com/WebAssembly/wabt/pull/979
There are links to these pages here:
https://github.com/WebAssembly/wabt

>
>> So I think one answer to this problem is "use the provided mandoc.css".
>
> Absolutely.
>
> Or if it doesn't meet your needs exactly, edit it, then use your
> edited version.
>
> Or if it doesn't meet your needs at all, write your own, using
> mandoc.css as documenation of the available classes.
>
>> However, that's not the default.
>> But perhaps it, or a variant of it, should be.
>
> I certainly love sensible defaults and hate the lack of them,
> but in the past, i considered sensible defaults impossible
> for "-O style=" because it is kind of hard to guess the file
> system layout on the user's system, so we don't know which
> absolute path to use in the line
> .
>

Personally, I think having a minimal default inline stylesheet is not that bad.
I like the fact that 'mandoc -T html' just works and produces a usable single
file by default.
(If there is inline css, it should be as minimal as possible because it should
not change in the future. Old manpages would need to be regenerated otherwise.)


> Let's try again.
> What do you think about the following plan:
>
>  1. Let's install /var/www/htdocs/mandoc.css by default.
>
>  2. When calling "mandoc -T html" without specifying "-O style=",
> fall back to "-O style=/var/www/htdocs/mandoc.css" by default.
> That might be sensible because it is adequate for local
> viewing of the file, which is likely intended with files
> generated in such a manual way.
> If the user then goes ahead and copies these files onto a
> webserver, they of course cannot work because the document root
> must be stripped from the "-O style=" argument in that case.
> Also, if the user copies these files onto a non-OpenBSD system,
> they stop working there, too.
>
>  3. To build HTML without any  whatsoever,
> require "-O style=" to be explicitly specified with an empty path.
>
>  4. Document all that in the mandoc(1) manual page below "HTML Output".
>
>  5. In man.cgi(8), we already use the equivalent
> of "-O style=/mandoc.css" by default, unless CSS_DIR is
> configured in cgi.h.  That won't change.
>
>> I guess one objection to always using mandoc.css is that it's
>> another file that may get lost.
>
> That's not really a counter-argument because nothing becomes worse.
> Currently, by default, you never have a good stylesheet, and if you
> configure one, it can already get lost, maybe even more easily
> because it is not installed by default.  With the above plan, you
> get a working stylesheet by default for some simple cases, and you
> can still build HTML files with a different one or even without any
> if you want to.
>
> By the way, not that man.conf(5) already supports the
>
>   output style /path/to/my.css
>
> directive.
>
>> And perhaps it's a touch too large to inline?
>
> Not a very convincing counter-argument either.  If you use an
> external stylesheet, which is almost always by far the most sensible
> thing to do, nothing gets inlined in the first place.  With the
> above plan, in the unusual case that the user explicitly request
> that no external stylesheet be used, inlining the whole thing is
> still better than inlining something stunted, like we do now, i
> think.  Look at arbitrary websites nowdays: almost all serve
> ridiculous amounts of boilerplate styling stuff.  The size of
> mandoc.css is really not a problem by comparision, and much less
> for a corner case that isn't recommended anyway.
>
>> But we can trim it down some to where I think it can be reas

mandoc -T html default style

2018-12-20 Thread Raphael Graf
The diff inserts some space above the footer.
This improves readability and makes it similar to the other output formats.

Here is an example found in the wild, demonstrating the problem:
https://webassembly.github.io/wabt/doc/wasm-objdump.1.html



Index: html.c
===
RCS file: /cvs/src/usr.bin/mandoc/html.c,v
retrieving revision 1.117
diff -u -p -u -p -r1.117 html.c
--- html.c  15 Dec 2018 23:33:20 -  1.117
+++ html.c  20 Dec 2018 13:38:14 -
@@ -183,6 +183,8 @@ print_gen_head(struct html *h)
t = print_otag(h, TAG_STYLE, "");
print_text(h, "table.head, table.foot { width: 100%; }");
print_endline(h);
+   print_text(h, "table.foot { margin-top: 3em; }");
+   print_endline(h);
print_text(h, "td.head-rtitle, td.foot-os { text-align: right; }");
print_endline(h);
print_text(h, "td.head-vol { text-align: center; }");




Re: armv7: banana pi, Allwinner A20 board

2014-10-20 Thread Raphael Graf
On Thu, October 16, 2014 11:40 pm, Patrick Wildt wrote:
 I do believe that this is a pmap issue.

 I just got hands on an Allwinner A20 and suffered the same issues:
 pool_setlowat crashing randomly, same for ahci and so on.

 I believe we are not syncing the PTEs correctly.

 Here?s the snippet from PTE_SYNC(), but PTE_SYNC_RANGE() has
 the same issue:

 #define   PTE_SYNC(pte)   
 \
 do {  \
   if (PMAP_NEEDS_PTE_SYNC) {  \
   paddr_t pa; \
   cpu_drain_writebuf();   \
   cpu_dcache_wb_range((vaddr_t)(pte), sizeof(pt_entry_t));\
   if (cpu_sdcache_enabled()) {\
   (void)pmap_extract(pmap_kernel(), (vaddr_t)(pte), pa); \
   cpu_sdcache_wb_range((vaddr_t)(pte), (paddr_t)(pa), \
   sizeof(pt_entry_t));\
   };  \
   cpu_drain_writebuf();   \
   }   \
 } while (/*CONSTCOND*/0)

 I believe that when we change things in the pagetables, we need to make
 sure the tables are synced before we?re going to use them.  In our case
 we believe that we are using uncached pagetables, which means that
 every write will directly hit the tables.

 But that does not have an affect on the write buffer.  The write buffer is 
 still
 there and has to be cleared manually.  If it isn?t, and something accesses
 an area which was just mapped, then we?re fucked.

 Therefore I firmly believe that the cpu_drain_writebuf() call has to be made
 regardless of PMAP_NEEDS_PTE_SYNC and that it has to be called before
 that if-clause.

 Doing that fixes my issues.

 \Patrick


I think this is correct. With the diff below, my A20 board doesn't panic 
anymore.

I still get a lot of messages like the following though:
pmap_fault_fixup: va 8000 ftype 1 u pte 7f24f02e



Index: sys/arch/arm/include/pmap.h
===
RCS file: /cvs/src/sys/arch/arm/include/pmap.h,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 pmap.h
--- sys/arch/arm/include/pmap.h 7 Oct 2014 10:10:58 -   1.27
+++ sys/arch/arm/include/pmap.h 20 Oct 2014 09:33:14 -
@@ -328,9 +328,9 @@ extern int pmap_needs_pte_sync;

 #definePTE_SYNC(pte)   
\
 do {   \
+   cpu_drain_writebuf();   \
if (PMAP_NEEDS_PTE_SYNC) {  \
paddr_t pa; \
-   cpu_drain_writebuf();   \
cpu_dcache_wb_range((vaddr_t)(pte), sizeof(pt_entry_t));\
if (cpu_sdcache_enabled()) {\
(void)pmap_extract(pmap_kernel(), (vaddr_t)(pte), pa); \
@@ -343,9 +343,9 @@ do {
\

 #definePTE_SYNC_RANGE(pte, cnt)
\
 do {   \
+   cpu_drain_writebuf();   \
if (PMAP_NEEDS_PTE_SYNC) {  \
paddr_t pa; \
-   cpu_drain_writebuf();   \
cpu_dcache_wb_range((vaddr_t)(pte), \
(cnt)  2); /* * sizeof(pt_entry_t) */ \
if (cpu_sdcache_enabled()) {\




Re: Patch: fix high capacity ( 2GB) eMMC support

2014-09-22 Thread Raphael Graf
On Sun, September 21, 2014 2:09 pm, Raphael Graf wrote:
 On Sat, September 20, 2014 7:45 pm, Jonathan Gray wrote:
 On Sat, Sep 20, 2014 at 06:01:51PM +0200, Cédric Tessier wrote:
 Hi,

 I've bought a BeagleBone Black rev. C board, and I was trying to install
 OpenBSD on it, but the internal eMMC was causing errors.

  sdmmc1: unknown CARD_TYPE 0x17
  scsibus1 at sdmmc1: 2 targets, initiator 0
  sd1 at scsibus1 targ 1 lun 0: SD/MMC, Drive #01,  SCSI2 0/direct fixed
  sd1: 1024MB, 512 bytes/sector, 2097152 sectors

 Card type and sectors count were wrong, and accessing the device was
 causing I/O errors.

 I've investigated the problem, and it looks like the support of
 High Capacity eMMC ( 2GB) is missing.

 I've written a quick and dirty patch (tested on 5.5 and snapshot) which fix
 all my issues.

 Modifications:
 - mask reserved bits for card type value

 These bits do not appear to be reserved.  In your case bit 4
 seems to indicate HS200/200 MHz clock capable.

 Bit 5 is HS400/400 MHz clock capable.

 - read sectors count from EXT_CSD
 - fix sectors count and enable SDHC if High Capacity eMMC is detected

 Is the old method of reading the block length still supported
 with emmc and csd ver  2?  That wasn't the case for normal sd card.

 It seems the emmc situation is a bit different as the capacity
 stored in a seperate place.

 +
 +   if (ext_csd[EXT_CSD_REV] = 2) {
 +   sectors =   ext_csd[EXT_CSD_SEC_COUNT + 0]  0  |
 +   ext_csd[EXT_CSD_SEC_COUNT + 1] 
  8  |
 +   ext_csd[EXT_CSD_SEC_COUNT + 2] 
  16 |
 +   ext_csd[EXT_CSD_SEC_COUNT + 3] 
  24;
 +   /*
 +* High capacity MMC seems to report a magic 4096 * 
 512 bytes
 +* capacity in csd, but ext_csd contains the real 
 sectors count
 +*/
 +   if ((sf-csd.capacity == (4096 * 512)) 
 +   (sectors  (2u * 1024 * 1024 * 1024) / 512)) {
 +   sf-flags |= SFF_SDHC;
 +   sf-csd.capacity = sectors;
 +   }

 I think this should change to

  if (sectors  (2u * 1024 * 1024 * 1024) / 512)
  sf-flags |= SFF_SDHC;
  sf-csd.capacity = sectors;

 All csd rev  2 cards should report valid sectors in the extended space.


 This seems not to be the case, the EXT_CSD_SEC_COUNT is only valid for
 capacities over 2G. I'd use this field only if it's not zero, like freebsd 
 does.

 Instead of masking the EXT_CSD_CARD_TYPE field, it may be better to just check
 for the relevant bits as in the diff below.

 Does this still work for you, Cédric?


 Index: sys/dev/sdmmc/sdmmc_mem.c
 ===
 RCS file: /cvs/src/sys/dev/sdmmc/sdmmc_mem.c,v
 retrieving revision 1.19
 diff -u -p -r1.19 sdmmc_mem.c
 --- sys/dev/sdmmc/sdmmc_mem.c 12 Jul 2014 18:48:52 -  1.19
 +++ sys/dev/sdmmc/sdmmc_mem.c 21 Sep 2014 12:02:35 -
 @@ -428,6 +428,7 @@ sdmmc_mem_mmc_init(struct sdmmc_softc *s
   u_int8_t ext_csd[512];
   int speed = 0;
   int hs_timing = 0;
 + u_int32_t sectors = 0;

   if (sf-csd.mmcver = MMC_CSD_MMCVER_4_0) {
   /* read EXT_CSD */
 @@ -439,18 +440,12 @@ sdmmc_mem_mmc_init(struct sdmmc_softc *s
   return error;
   }

 - switch (ext_csd[EXT_CSD_CARD_TYPE]) {
 - case EXT_CSD_CARD_TYPE_26M:
 - speed = 26000;
 - break;
 - case EXT_CSD_CARD_TYPE_52M:
 - case EXT_CSD_CARD_TYPE_52M_V18:
 - case EXT_CSD_CARD_TYPE_52M_V12:
 - case EXT_CSD_CARD_TYPE_52M_V12_18:
 + if (ext_csd[EXT_CSD_CARD_TYPE]  EXT_CSD_CARD_TYPE_52M) {
   speed = 52000;
   hs_timing = 1;
 - break;
 - default:
 + } else if (ext_csd[EXT_CSD_CARD_TYPE]  EXT_CSD_CARD_TYPE_26M) {
 + speed = 26000;
 + } else {
   printf(%s: unknown CARD_TYPE 0x%x\n, DEVNAME(sc),
   ext_csd[EXT_CSD_CARD_TYPE]);
   }
 @@ -487,6 +482,16 @@ sdmmc_mem_mmc_init(struct sdmmc_softc *s
   printf(%s, HS_TIMING set failed\n, 
 DEVNAME(sc));
   return EINVAL;
   }
 + }
 +
 + sectors = ext_csd[EXT_CSD_SEC_COUNT + 0]  0 |
 + ext_csd[EXT_CSD_SEC_COUNT + 1]  8  |
 + ext_csd[EXT_CSD_SEC_COUNT + 2]  16 |
 + ext_csd[EXT_CSD_SEC_COUNT + 3]  24;
 +
 + if (sectors != 0) {
 + sf-flags |= SFF_SDHC;
 + sf-csd.capacity = sectors;
   }
   }

 Index: sys/dev

Re: Patch: fix high capacity ( 2GB) eMMC support

2014-09-21 Thread Raphael Graf
On Sat, September 20, 2014 7:45 pm, Jonathan Gray wrote:
 On Sat, Sep 20, 2014 at 06:01:51PM +0200, Cédric Tessier wrote:
 Hi,

 I've bought a BeagleBone Black rev. C board, and I was trying to install
 OpenBSD on it, but the internal eMMC was causing errors.

  sdmmc1: unknown CARD_TYPE 0x17
  scsibus1 at sdmmc1: 2 targets, initiator 0
  sd1 at scsibus1 targ 1 lun 0: SD/MMC, Drive #01,  SCSI2 0/direct fixed
  sd1: 1024MB, 512 bytes/sector, 2097152 sectors

 Card type and sectors count were wrong, and accessing the device was
 causing I/O errors.

 I've investigated the problem, and it looks like the support of
 High Capacity eMMC ( 2GB) is missing.

 I've written a quick and dirty patch (tested on 5.5 and snapshot) which fix
 all my issues.

 Modifications:
 - mask reserved bits for card type value

 These bits do not appear to be reserved.  In your case bit 4
 seems to indicate HS200/200 MHz clock capable.

 Bit 5 is HS400/400 MHz clock capable.

 - read sectors count from EXT_CSD
 - fix sectors count and enable SDHC if High Capacity eMMC is detected

 Is the old method of reading the block length still supported
 with emmc and csd ver  2?  That wasn't the case for normal sd card.

 It seems the emmc situation is a bit different as the capacity
 stored in a seperate place.

 +
 +if (ext_csd[EXT_CSD_REV] = 2) {
 +sectors =   ext_csd[EXT_CSD_SEC_COUNT + 0]  0  |
 +ext_csd[EXT_CSD_SEC_COUNT + 1] 
  8  |
 +ext_csd[EXT_CSD_SEC_COUNT + 2] 
  16 |
 +ext_csd[EXT_CSD_SEC_COUNT + 3] 
  24;
 +/*
 + * High capacity MMC seems to report a magic 4096 * 
 512 bytes
 + * capacity in csd, but ext_csd contains the real 
 sectors count
 + */
 +if ((sf-csd.capacity == (4096 * 512)) 
 +(sectors  (2u * 1024 * 1024 * 1024) / 512)) {
 +sf-flags |= SFF_SDHC;
 +sf-csd.capacity = sectors;
 +}

 I think this should change to

   if (sectors  (2u * 1024 * 1024 * 1024) / 512)
   sf-flags |= SFF_SDHC;
   sf-csd.capacity = sectors;

 All csd rev  2 cards should report valid sectors in the extended space.


This seems not to be the case, the EXT_CSD_SEC_COUNT is only valid for
capacities over 2G. I'd use this field only if it's not zero, like freebsd does.

Instead of masking the EXT_CSD_CARD_TYPE field, it may be better to just check
for the relevant bits as in the diff below.

Does this still work for you, Cédric?


Index: sys/dev/sdmmc/sdmmc_mem.c
===
RCS file: /cvs/src/sys/dev/sdmmc/sdmmc_mem.c,v
retrieving revision 1.19
diff -u -p -r1.19 sdmmc_mem.c
--- sys/dev/sdmmc/sdmmc_mem.c   12 Jul 2014 18:48:52 -  1.19
+++ sys/dev/sdmmc/sdmmc_mem.c   21 Sep 2014 12:02:35 -
@@ -428,6 +428,7 @@ sdmmc_mem_mmc_init(struct sdmmc_softc *s
u_int8_t ext_csd[512];
int speed = 0;
int hs_timing = 0;
+   u_int32_t sectors = 0;

if (sf-csd.mmcver = MMC_CSD_MMCVER_4_0) {
/* read EXT_CSD */
@@ -439,18 +440,12 @@ sdmmc_mem_mmc_init(struct sdmmc_softc *s
return error;
}

-   switch (ext_csd[EXT_CSD_CARD_TYPE]) {
-   case EXT_CSD_CARD_TYPE_26M:
-   speed = 26000;
-   break;
-   case EXT_CSD_CARD_TYPE_52M:
-   case EXT_CSD_CARD_TYPE_52M_V18:
-   case EXT_CSD_CARD_TYPE_52M_V12:
-   case EXT_CSD_CARD_TYPE_52M_V12_18:
+   if (ext_csd[EXT_CSD_CARD_TYPE]  EXT_CSD_CARD_TYPE_52M) {
speed = 52000;
hs_timing = 1;
-   break;
-   default:
+   } else if (ext_csd[EXT_CSD_CARD_TYPE]  EXT_CSD_CARD_TYPE_26M) {
+   speed = 26000;
+   } else {
printf(%s: unknown CARD_TYPE 0x%x\n, DEVNAME(sc),
ext_csd[EXT_CSD_CARD_TYPE]);
}
@@ -487,6 +482,16 @@ sdmmc_mem_mmc_init(struct sdmmc_softc *s
printf(%s, HS_TIMING set failed\n, 
DEVNAME(sc));
return EINVAL;
}
+   }
+
+   sectors = ext_csd[EXT_CSD_SEC_COUNT + 0]  0 |
+   ext_csd[EXT_CSD_SEC_COUNT + 1]  8  |
+   ext_csd[EXT_CSD_SEC_COUNT + 2]  16 |
+   ext_csd[EXT_CSD_SEC_COUNT + 3]  24;
+
+   if (sectors != 0) {
+   sf-flags |= SFF_SDHC;
+   sf-csd.capacity = sectors;
}
}

Index: sys/dev/sdmmc/sdmmcreg.h

Re: run(4) firmware update; please test

2014-05-16 Thread Raphael Graf
On Thu, May 15, 2014 11:35 am, Stefan Sperling wrote:
 This firmware update to version 0.33 is a prequisite for
 newer run(4) devices which are not yet supported.

 Can active users of run(4) devices please test this update
 to make sure no regressions are introduced for already working
 devices? I don't have a supported run(4) device to test with.


This one keeps working as expected:

run0 at uhub13 port 1 Belkin Belkin Enhanced Wireless USB Adapter rev 
2.00/1.01 addr 2
run0: MAC/BBP RT3070 (rev 0x0201), RF RT3020 (MIMO 1T1R), address 
00:22:75:f5:df:b8




Re: Update the sdmmmc stack to take care of the SMC_CAPS_SINGLE_ONLY capability

2013-10-19 Thread Raphael Graf
On Fri, October 18, 2013 9:54 am, Sylvestre Gallon wrote:
 Hi tech@

 Here is a diff to allow the sdmmc SMC_CAPS_SINGLE_ONLY caps to do
 something. The bits I take are from NetBSD and it works well with
 ommmc(4) on my Beagle Bone Black.

 This capability force the sdmmc stack to only issue single blocks
 transfers. It is usefull for debug purpose and/or for broken sdmmmc
 controller.

 Any OK/Comments ?

This looks good to me. I have tested it with ommmc(4), if needed I can
test with pxammc(4) next week.


 Cheers,

 Index: sdmmc_mem.c
 ===
 RCS file: /cvs/src/sys/dev/sdmmc/sdmmc_mem.c,v
 retrieving revision 1.17
 diff -u -p -u -p -r1.17 sdmmc_mem.c
 --- sdmmc_mem.c   12 Sep 2013 11:54:04 -  1.17
 +++ sdmmc_mem.c   18 Oct 2013 09:31:15 -
 @@ -42,6 +42,14 @@ intsdmmc_mem_mmc_switch(struct sdmmc_fu

  int  sdmmc_mem_sd_init(struct sdmmc_softc *, struct sdmmc_function *);
  int  sdmmc_mem_mmc_init(struct sdmmc_softc *, struct sdmmc_function *);
 +int  sdmmc_mem_single_read_block(struct sdmmc_function *, int, u_char *,
 + size_t);
 +int  sdmmc_mem_read_block_subr(struct sdmmc_function *, int, u_char *,
 + size_t);
 +int  sdmmc_mem_single_write_block(struct sdmmc_function *, int, u_char *,
 + size_t);
 +int  sdmmc_mem_write_block_subr(struct sdmmc_function *, int, u_char *,
 + size_t);

  #ifdef SDMMC_DEBUG
  #define DPRINTF(s)   printf s
 @@ -551,14 +559,13 @@ sdmmc_mem_set_blocklen(struct sdmmc_soft
  }

  int
 -sdmmc_mem_read_block(struct sdmmc_function *sf, int blkno, u_char *data,
 +sdmmc_mem_read_block_subr(struct sdmmc_function *sf, int blkno, u_char *data,
  size_t datalen)
  {
   struct sdmmc_softc *sc = sf-sc;
   struct sdmmc_command cmd;
   int error;

 - rw_enter_write(sc-sc_lock);

   if ((error = sdmmc_select_card(sc, sf)) != 0)
   goto err;
 @@ -602,20 +609,53 @@ sdmmc_mem_read_block(struct sdmmc_functi
   } while (!ISSET(MMC_R1(cmd.c_resp), MMC_R1_READY_FOR_DATA));

  err:
 - rw_exit(sc-sc_lock);
 - return error;
 + return (error);
  }

  int
 -sdmmc_mem_write_block(struct sdmmc_function *sf, int blkno, u_char *data,
 +sdmmc_mem_single_read_block(struct sdmmc_function *sf, int blkno, u_char 
 *data,
 +size_t datalen)
 +{
 + int error;
 + int i;
 +
 + for (i = 0; i  datalen / sf-csd.sector_size; i++) {
 + error = sdmmc_mem_read_block_subr(sf, blkno + i, data + i *
 + sf-csd.sector_size, sf-csd.sector_size);
 + if (error)
 + break;
 + }
 +
 + return (error);
 +}
 +
 +int
 +sdmmc_mem_read_block(struct sdmmc_function *sf, int blkno, u_char *data,
  size_t datalen)
  {
   struct sdmmc_softc *sc = sf-sc;
 - struct sdmmc_command cmd;
   int error;

   rw_enter_write(sc-sc_lock);

 + if (ISSET(sc-sc_caps, SMC_CAPS_SINGLE_ONLY)) {
 + error = sdmmc_mem_single_read_block(sf, blkno, data, datalen);
 + } else {
 + error = sdmmc_mem_read_block_subr(sf, blkno, data, datalen);
 + }
 +
 + rw_exit(sc-sc_lock);
 + return (error);
 +}
 +
 +int
 +sdmmc_mem_write_block_subr(struct sdmmc_function *sf, int blkno, u_char 
 *data,
 +size_t datalen)
 +{
 + struct sdmmc_softc *sc = sf-sc;
 + struct sdmmc_command cmd;
 + int error;
 +
   if ((error = sdmmc_select_card(sc, sf)) != 0)
   goto err;

 @@ -657,6 +697,41 @@ sdmmc_mem_write_block(struct sdmmc_funct
   } while (!ISSET(MMC_R1(cmd.c_resp), MMC_R1_READY_FOR_DATA));

  err:
 + return (error);
 +}
 +
 +int
 +sdmmc_mem_single_write_block(struct sdmmc_function *sf, int blkno, u_char 
 *data,
 +size_t datalen)
 +{
 + int error;
 + int i;
 +
 + for (i = 0; i  datalen / sf-csd.sector_size; i++) {
 + error = sdmmc_mem_write_block_subr(sf, blkno + i, data + i *
 + sf-csd.sector_size, sf-csd.sector_size);
 + if (error)
 + break;
 + }
 +
 + return (error);
 +}
 +
 +int
 +sdmmc_mem_write_block(struct sdmmc_function *sf, int blkno, u_char *data,
 +size_t datalen)
 +{
 + struct sdmmc_softc *sc = sf-sc;
 + int error;
 +
 + rw_enter_write(sc-sc_lock);
 +
 + if (ISSET(sc-sc_caps, SMC_CAPS_SINGLE_ONLY)) {
 + error = sdmmc_mem_single_write_block(sf, blkno, data, datalen);
 + } else {
 + error = sdmmc_mem_write_block_subr(sf, blkno, data, datalen);
 + }
 +
   rw_exit(sc-sc_lock);
 - return error;
 + return (error);
  }






azalia acer quirks

2013-09-14 Thread Raphael Graf
Without this diff, I just get silence from an Acer Extensa 6700.
I don't know if this is the right way to fix it..
Comments?

Index: sys/dev/pci/azalia_codec.c
===
RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v
retrieving revision 1.154
diff -u -p -u -p -r1.154 azalia_codec.c
--- sys/dev/pci/azalia_codec.c  27 May 2013 21:19:31 -  1.154
+++ sys/dev/pci/azalia_codec.c  14 Sep 2013 10:41:31 -
@@ -74,6 +74,8 @@ azalia_codec_init_vtbl(codec_t *this)
break;
case 0x10ec0260:
this-name = Realtek ALC260;
+   if (this-subid == 0x008f1025)
+   this-qrks |= AZ_QRK_GPIO_UNMUTE_0;
break;
case 0x10ec0262:
this-name = Realtek ALC262;




azalia0 at pci0 dev 27 function 0 Intel 82801FB HD Audio rev 0x04: msi
azalia0: codecs: Realtek ALC260, Conexant/0x2bfa, using Realtek ALC260
audio0 at azalia0


Domain /dev/pci0:
 0:0:0: Intel 82915GM Host
0x: Vendor ID: 8086 Product ID: 2590
0x0004: Command: 0106 Status: 2090
0x0008: Class: 06 Subclass: 00 Interface: 00 Revision: 03
0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00
0x0010: BAR empty ()
0x0014: BAR empty ()
0x0018: BAR empty ()
0x001c: BAR empty ()
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID: 1025 Product ID: 008f
0x0030: Expansion ROM Base Address: 
0x0038: 
0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00
0x00e0: Capability 0x09: Vendor Specific
 0:2:0: Intel 82915GM Video
0x: Vendor ID: 8086 Product ID: 2592
0x0004: Command: 0007 Status: 0090
0x0008: Class: 03 Subclass: 00 Interface: 00 Revision: 03
0x000c: BIST: 00 Header Type: 80 Latency Timer: 00 Cache Line Size: 00
0x0010: BAR mem 32bit addr: 0xb008/0x0008
0x0014: BAR io addr: 0x1800/0x0008
0x0018: BAR mem prefetchable 32bit addr: 0xc000/0x1000
0x001c: BAR mem 32bit addr: 0xb000/0x0004
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID: 1025 Product ID: 008f
0x0030: Expansion ROM Base Address: 
0x0038: 
0x003c: Interrupt Pin: 01 Line: 0a Min Gnt: 00 Max Lat: 00
0x00d0: Capability 0x01: Power Management
 0:2:1: Intel 82915GM Video
0x: Vendor ID: 8086 Product ID: 2792
0x0004: Command:  Status: 0090
0x0008: Class: 03 Subclass: 80 Interface: 00 Revision: 03
0x000c: BIST: 00 Header Type: 80 Latency Timer: 00 Cache Line Size: 00
0x0010: BAR mem 32bit addr: 0x/0x0008
0x0014: BAR empty ()
0x0018: BAR empty ()
0x001c: BAR empty ()
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID: 1025 Product ID: 008f
0x0030: Expansion ROM Base Address: 
0x0038: 
0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00
0x00d0: Capability 0x01: Power Management
 0:27:0: Intel 82801FB HD Audio
0x: Vendor ID: 8086 Product ID: 2668
0x0004: Command: 0006 Status: 0010
0x0008: Class: 04 Subclass: 03 Interface: 00 Revision: 04
0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00
0x0010: BAR mem 64bit addr: 0xd000c000/0x4000
0x0018: BAR empty ()
0x001c: BAR empty ()
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID: 1025 Product ID: 008f
0x0030: Expansion ROM Base Address: 
0x0038: 
0x003c: Interrupt Pin: 01 Line: 00 Min Gnt: 00 Max Lat: 00
0x0050: Capability 0x01: Power Management
0x0060: Capability 0x05: Message Signaled Interrupts (MSI)
0x0070: Capability 0x10: PCI Express
 0:28:0: Intel 82801FB PCIE
0x: Vendor ID: 8086 Product ID: 2660
0x0004: Command:  Status: 0010
0x0008: Class: 06 Subclass: 04 Interface: 00 Revision: 04
0x000c: BIST: 00 Header Type: 81 Latency Timer: 00 Cache Line Size: 08
0x0010: 
0x0014: 
0x0018: Primary Bus: 0 Secondary Bus: 9 Subordinate Bus: 9
Secondary Latency Timer: 00
0x001c: I/O Base: 00 I/O Limit: 00 Secondary Status: 2000
0x0020: Memory Base: fff0 Memory Limit: 
0x0024: Prefetch Memory Base: fff1 Prefetch Memory Limit: 0001
0x0028: Prefetch Memory Base Upper 32 Bits: 

Re: beaglebone

2013-04-26 Thread Raphael Graf
On Thu, April 25, 2013 7:30 pm, Alexey E. Suslikov wrote:
 Raphael Graf r at undefined.ch writes:

 I have a beaglebone (AM3359) running OpenBSD, see below.
 Is there any interest in such code?

 Diffs are interesting. Teasers are not.


So here's what I have at the moment.
Some parts are just horrible hacks (notably the prcm stuff), beware.
I'll start sending (smaller) diffs when ready.

Index: beagle/beagle_machdep.c
===
RCS file: /cvs/src/sys/arch/beagle/beagle/beagle_machdep.c,v
retrieving revision 1.15
diff -u -p -u -p -r1.15 beagle_machdep.c
--- beagle/beagle_machdep.c 30 Aug 2012 15:51:13 -  1.15
+++ beagle/beagle_machdep.c 26 Apr 2013 14:43:24 -
@@ -882,6 +882,9 @@ initarm(void *arg0, void *arg1, void *ar
case BOARD_ID_OMAP3_BEAGLE:
printf(board type: beagle\n);
break;
+   case BOARD_ID_AM335X_BEAGLEBONE:
+   printf(board type: beaglebone\n);
+   break;
case BOARD_ID_OMAP3_OVERO:
printf(board type: overo\n);
break;
@@ -979,6 +982,9 @@ consinit(void)
case BOARD_ID_OMAP3_BEAGLE:
case BOARD_ID_OMAP3_OVERO:
paddr = 0x4902;
+   break;
+   case BOARD_ID_AM335X_BEAGLEBONE:
+   paddr = 0x44E09000; /* UART0 */
break;
case BOARD_ID_OMAP4_PANDA:
paddr = 0x4802;
Index: conf/GENERIC
===
RCS file: /cvs/src/sys/arch/beagle/conf/GENERIC,v
retrieving revision 1.14
diff -u -p -u -p -r1.14 GENERIC
--- conf/GENERIC27 Sep 2012 14:01:35 -  1.14
+++ conf/GENERIC26 Apr 2013 14:43:24 -
@@ -68,6 +68,7 @@ prcm* at soc? # power/clock controlle
 omdog* at soc? # watchdog timer
 omgpio*at soc? # user-visible GPIO pins?
 gptimer*   at soc? # general purpose timers
+dmtimer*   at soc? # general purpose timers
 ommmc* at soc? # SD/MMC card controller
 omusbtll*  at soc?

Index: conf/RAMDISK
===
RCS file: /cvs/src/sys/arch/beagle/conf/RAMDISK,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 RAMDISK
--- conf/RAMDISK27 Sep 2012 14:01:35 -  1.16
+++ conf/RAMDISK26 Apr 2013 14:43:24 -
@@ -73,6 +73,7 @@ prcm* at soc? # power/clock controlle
 omdog* at soc? # watchdog timer
 omgpio*at soc? # user-visible GPIO pins?
 gptimer*   at soc? # general purpose timers
+dmtimer*   at soc? # general purpose timers
 ommmc* at soc? # SD/MMC card controller
 omusbtll*  at soc?

Index: conf/files.beagle
===
RCS file: /cvs/src/sys/arch/beagle/conf/files.beagle,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 files.beagle
--- conf/files.beagle   27 Mar 2013 17:33:13 -  1.12
+++ conf/files.beagle   26 Apr 2013 14:43:24 -
@@ -31,6 +31,7 @@ attach omap at mainbus
 file   arch/beagle/dev/omap.c  omap
 file   arch/beagle/dev/omap3.c omap
 file   arch/beagle/dev/omap4.c omap
+file   arch/beagle/dev/am335x.comap

 # cortex based peripherals
 device ampintc
@@ -62,6 +63,10 @@ file arch/beagle/dev/intc.c  intc
 device gptimer
 attach gptimer at soc
 file   arch/beagle/dev/gptimer.c   gptimer
+
+device dmtimer
+attach dmtimer at soc
+file   arch/beagle/dev/dmtimer.c   dmtimer

 device omdog
 attach omdog at soc
Index: dev/am335x.c
===
RCS file: dev/am335x.c
diff -N dev/am335x.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ dev/am335x.c26 Apr 2013 14:43:24 -
@@ -0,0 +1,161 @@
+/* $OpenBSD: omap3.c,v 1.4 2011/11/10 23:43:01 uwe Exp $ */
+
+/*
+ * Copyright (c) 2011 Uwe Stuehler u...@openbsd.org
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include sys

beaglebone

2013-04-25 Thread Raphael Graf
I have a beaglebone (AM3359) running OpenBSD, see below.
Is there any interest in such code?


OpenBSD/beagle booting ...
arg0 0x0 arg1 0xe05 arg2 0x8100
atag core flags 0 pagesize 0 rootdev 0
atag mem start 0x8000 size 0x1000
atag cmdline [sd0]
bootfile: sd0
bootargs:
memory size derived from u-boot
bootconf.mem[0].address = 8000 pages 65536/0x1000
Allocating page tables
freestart = 0x00621000, free_pages = 530911 (0x000819df)
IRQ stack: p0x81fd1000 v0xc1fd1000
ABT stack: p0x81fd v0xc1fd
UND stack: p0x81fcf000 v0xc1fcf000
SVC stack: p0x81fcd000 v0xc1fcd000
Creating L1 page table at 0x81ffc000
Mapping kernel
Constructing L2 page tables
undefined page pmap [ no symbol table formats found ]
board type: beaglebone
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2013 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 5.3-current (GENERIC) #0: Thu Apr 25 10:51:58 MDT 2013
r...@noname.my.domain:/usr/src/sys/arch/beagle/compile/GENERIC
real mem  = 268435456 (256MB)
avail mem = 255819776 (243MB)
mainbus0 at root
cpu0 at mainbus0: ARM Cortex A8 R3 rev 2 (ARMv7 core)
cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu0: 32KB(64b/l,4way) I-cache, 32KB(64b/l,4way) wr-back D-cache
omap0 at mainbus0: BeagleBone
prcm0 at omap0 rev 0.2
intc0 at omap0 rev 5.0
dmtimer0 at omap0 rev 0.1
dmtimer1 at omap0 rev 0.1
omdog0 at omap0 rev 0.1
ommmc0 at omap0 rev 3.1
sdmmc0 at ommmc0
com0 at omap0: ti16750, 64 byte fifo
com0: console
/dev/ksyms: Symbol table not valid.
scsibus0 at sdmmc0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0: SD/MMC, Drive #01,  SCSI2 0/direct fixed
sd0: 7580MB, 512 bytes/sector, 15523840 sectors
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
boot device: sd0
root on sd0a (2579d6d61b20ccb7.a) swap on sd0b dump on sd0b
WARNING: CHECK AND RESET THE DATE!
Automatic boot in progress: starting file system checks.
/dev/rsd0a: file system is clean; not checking
setting tty flags
pf enabled
ddb.console: 0 - 1
starting network
starting early daemons: syslogd pflogd.
starting RPC daemons:.
savecore: no core dump
checking quotas: done.
kvm_mkdb: can't open /dev/ksyms
clearing /tmp
starting pre-securelevel daemons:.
setting kernel security level: kern.securelevel: 0 - 1
creating runtime link editor directory cache.
preserving editor files.
starting network daemons: sshd sendmail inetd sndiod.
starting local daemons: cron.
Thu Apr 25 11:02:09 MDT 2013

OpenBSD/beagle (noname.my.domain) (console)

login:




Re: beaglebone JTAG (FT2232H)

2013-01-31 Thread Raphael Graf
On Thu, January 31, 2013 10:31 am, Martin Pieuchot wrote:
 On 30/01/13(Wed) 13:19, Raphael Graf wrote:
 On Wed, January 30, 2013 10:52 am, Martin Pieuchot wrote:
  On 27/01/13(Sun) 16:13, Raphael Graf wrote:
  The diff below makes the jtag and serial interfaces of the beaglebone 
  (FT2232H)
  work simultaneously.
  This is how the beaglebone shows up:
 
  uhub8 at uhub0 port 1 Standard Microsystems product 0x2412 rev 
  2.00/b.b2 addr 3
  uftdi0 at uhub8 port 1 configuration 1 interface 1 FTDI 
  BeagleBone/XDS100V2 rev 2.00/7.00 addr 4
  ucom0 at uftdi0 portno 2
  ugen0 at uhub8 port 1 configuration 1 FTDI BeagleBone/XDS100V2 rev 
  2.00/7.00 addr 4
 
  Like this, openocd (using ugen) and cu both work.
 
  It is just assumed that interface 0 is used for jtag, not sure if this is
  always true. I'm also unsure if the diff would break other devices.
  Can someone comment on this?
 
  Your diff looks correct and after looking at how the USB drivers are
  matched it seems obvious to me that changing the configuration in this
  function is not the right thing to do.
 
  I just rewrote your diff to keep only one (iface == NULL) check, I think
  it is clearer like that. Are you ok with this version?

 Yes, thanks.
 Could you take a quick look at the uftdi_attach function?
 I think some 'if (uaa-iface == NULL)' code could be removed there.

 Right, here's an updated diff, is it still ok for you?

Yes, i've tested it again with the beaglebone.

Thanks!

r


 M.

 Index: uftdi.c
 ===
 RCS file: /home/ncvs/src/sys/dev/usb/uftdi.c,v
 retrieving revision 1.63
 diff -u -p -r1.63 uftdi.c
 --- uftdi.c   11 Sep 2012 16:04:44 -  1.63
 +++ uftdi.c   31 Jan 2013 08:59:50 -
 @@ -748,39 +748,29 @@ int
  uftdi_match(struct device *parent, void *match, void *aux)
  {
   struct usb_attach_arg *uaa = aux;
 - usbd_status err;
 - u_int8_t nifaces;

 - if (usb_lookup(uftdi_devs, uaa-vendor, uaa-product) == NULL)
 + /*
 +  * Only match when looping against interfaces to allow ugen(4)
 +  * to take over the interface 0, JTAG on USB, on some models.
 +  */
 + if (uaa-iface == NULL)
   return (UMATCH_NONE);

 - /* Get the number of interfaces. */
 - if (uaa-iface != NULL) {
 - nifaces = uaa-nifaces;
 - } else {
 - err = usbd_set_config_index(uaa-device, UFTDI_CONFIG_INDEX, 1);
 - if (err)
 - return (UMATCH_NONE);
 - err = usbd_interface_count(uaa-device, nifaces);
 - if (err)
 - return (UMATCH_NONE);
 - usbd_set_config_index(uaa-device, USB_UNCONFIG_INDEX, 1);
 - }
 + if (usb_lookup(uftdi_devs, uaa-vendor, uaa-product) == NULL)
 + return (UMATCH_NONE);

   /* JTAG on USB interface 0 */
   if (uaa-vendor == USB_VENDOR_FTDI 
 - uaa-product == USB_PRODUCT_FTDI_OPENRD 
 + (uaa-product == USB_PRODUCT_FTDI_OPENRD ||
 + uaa-product == USB_PRODUCT_FTDI_SERIAL_2232C) 
   uaa-ifaceno == 0)
   return (UMATCH_NONE);

 - if (nifaces = 1)
 + if (uaa-nifaces = 1)
   return (UMATCH_VENDOR_PRODUCT);

   /* Dual UART chip */
 - if (uaa-iface != NULL)
 - return (UMATCH_VENDOR_IFACESUBCLASS);
 - else
 - return (UMATCH_NONE);
 + return (UMATCH_VENDOR_IFACESUBCLASS);
  }

  void
 @@ -789,34 +779,15 @@ uftdi_attach(struct device *parent, stru
   struct uftdi_softc *sc = (struct uftdi_softc *)self;
   struct usb_attach_arg *uaa = aux;
   usbd_device_handle dev = uaa-device;
 - usbd_interface_handle iface;
 + usbd_interface_handle iface = uaa-iface;
   usb_interface_descriptor_t *id;
   usb_endpoint_descriptor_t *ed;
   char *devname = sc-sc_dev.dv_xname;
   int i;
 - usbd_status err;
   struct ucom_attach_args uca;

   DPRINTFN(10,(\nuftdi_attach: sc=%p\n, sc));

 - if (uaa-iface == NULL) {
 - /* Move the device into the configured state. */
 - err = usbd_set_config_index(dev, UFTDI_CONFIG_INDEX, 1);
 - if (err) {
 - printf(%s: failed to set configuration, err=%s\n,
 - sc-sc_dev.dv_xname, usbd_errstr(err));
 - goto bad;
 - }
 -
 - err = usbd_device2interface_handle(dev, UFTDI_IFACE_INDEX, 
 iface);
 - if (err) {
 - printf(%s: failed to get interface, err=%s\n,
 - sc-sc_dev.dv_xname, usbd_errstr(err));
 - goto bad;
 - }
 - } else
 - iface = uaa-iface;
 -
   id = usbd_get_interface_descriptor(iface);

   sc-sc_udev = dev;
 @@ -871,10 +842,7 @@ uftdi_attach(struct device *parent, stru
   goto bad;
   }

 - if (uaa-iface == NULL)
 - uca.portno = FTDI_PIT_SIOA;
 - else

Re: beaglebone JTAG (FT2232H)

2013-01-29 Thread Raphael Graf
On Mon, January 28, 2013 11:29 am, Stuart Henderson wrote:
 Have you checked if this is still necessary? libusb on OpenBSD is now able to 
 talk to devices claimed by drivers other than ugen.

Yes, I suspect it is still necessary to use ugen.
It seems like libusb does not support bulk transfers otherwise.


uhub8 at uhub0 port 1 Standard Microsystems product 0x2412 rev 2.00/b.b2 addr 
3
uftdi0 at uhub8 port 1 configuration 1 interface 0 FTDI BeagleBone/XDS100V2 
rev 2.00/7.00 addr 4
ucom0 at uftdi0 portno 1
uftdi1 at uhub8 port 1 configuration 1 interface 1 FTDI BeagleBone/XDS100V2 
rev 2.00/7.00 addr 4
ucom1 at uftdi1 portno 2

$ openocd -f /usr/local/share/openocd/scripts/board/ti_beaglebone.cfg
Open On-Chip Debugger 0.6.1 (2013-01-29-22:25)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 16000 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
Warn : unable to open ftdi device (trying more): device not found
Error: ftdi_write_data: usb bulk write failed
Error: couldn't initialize data bits low byte
Error: couldn't initialize FT2232 with 'xds100v2' layout
in procedure 'init'



 Raphael Graf r...@undefined.ch wrote:

The diff below makes the jtag and serial interfaces of the beaglebone
(FT2232H)
work simultaneously.
This is how the beaglebone shows up:

uhub8 at uhub0 port 1 Standard Microsystems product 0x2412 rev
2.00/b.b2 addr 3
uftdi0 at uhub8 port 1 configuration 1 interface 1 FTDI
BeagleBone/XDS100V2 rev 2.00/7.00 addr 4
ucom0 at uftdi0 portno 2
ugen0 at uhub8 port 1 configuration 1 FTDI BeagleBone/XDS100V2 rev
2.00/7.00 addr 4

Like this, openocd (using ugen) and cu both work.

It is just assumed that interface 0 is used for jtag, not sure if this
is
always true. I'm also unsure if the diff would break other devices.
Can someone comment on this?

Thanks


Index: uftdi.c
===
RCS file: /cvs/src/sys/dev/usb/uftdi.c,v
retrieving revision 1.63
diff -u -p -r1.63 uftdi.c
--- uftdi.c   11 Sep 2012 16:04:44 -  1.63
+++ uftdi.c   27 Jan 2013 13:20:53 -
@@ -748,28 +748,21 @@ int
 uftdi_match(struct device *parent, void *match, void *aux)
 {
  struct usb_attach_arg *uaa = aux;
- usbd_status err;
  u_int8_t nifaces;

  if (usb_lookup(uftdi_devs, uaa-vendor, uaa-product) == NULL)
  return (UMATCH_NONE);

  /* Get the number of interfaces. */
- if (uaa-iface != NULL) {
+ if (uaa-iface != NULL)
  nifaces = uaa-nifaces;
- } else {
- err = usbd_set_config_index(uaa-device, UFTDI_CONFIG_INDEX, 1);
- if (err)
- return (UMATCH_NONE);
- err = usbd_interface_count(uaa-device, nifaces);
- if (err)
- return (UMATCH_NONE);
- usbd_set_config_index(uaa-device, USB_UNCONFIG_INDEX, 1);
- }
+ else
+ return UMATCH_NONE;

  /* JTAG on USB interface 0 */
  if (uaa-vendor == USB_VENDOR_FTDI 
- uaa-product == USB_PRODUCT_FTDI_OPENRD 
+ (uaa-product == USB_PRODUCT_FTDI_OPENRD ||
+ uaa-product == USB_PRODUCT_FTDI_SERIAL_2232C) 
  uaa-ifaceno == 0)
  return (UMATCH_NONE);





beaglebone JTAG (FT2232H)

2013-01-27 Thread Raphael Graf
The diff below makes the jtag and serial interfaces of the beaglebone (FT2232H)
work simultaneously.
This is how the beaglebone shows up:

uhub8 at uhub0 port 1 Standard Microsystems product 0x2412 rev 2.00/b.b2 addr 
3
uftdi0 at uhub8 port 1 configuration 1 interface 1 FTDI BeagleBone/XDS100V2 
rev 2.00/7.00 addr 4
ucom0 at uftdi0 portno 2
ugen0 at uhub8 port 1 configuration 1 FTDI BeagleBone/XDS100V2 rev 2.00/7.00 
addr 4

Like this, openocd (using ugen) and cu both work.

It is just assumed that interface 0 is used for jtag, not sure if this is
always true. I'm also unsure if the diff would break other devices.
Can someone comment on this?

Thanks


Index: uftdi.c
===
RCS file: /cvs/src/sys/dev/usb/uftdi.c,v
retrieving revision 1.63
diff -u -p -r1.63 uftdi.c
--- uftdi.c 11 Sep 2012 16:04:44 -  1.63
+++ uftdi.c 27 Jan 2013 13:20:53 -
@@ -748,28 +748,21 @@ int
 uftdi_match(struct device *parent, void *match, void *aux)
 {
struct usb_attach_arg *uaa = aux;
-   usbd_status err;
u_int8_t nifaces;

if (usb_lookup(uftdi_devs, uaa-vendor, uaa-product) == NULL)
return (UMATCH_NONE);

/* Get the number of interfaces. */
-   if (uaa-iface != NULL) {
+   if (uaa-iface != NULL)
nifaces = uaa-nifaces;
-   } else {
-   err = usbd_set_config_index(uaa-device, UFTDI_CONFIG_INDEX, 1);
-   if (err)
-   return (UMATCH_NONE);
-   err = usbd_interface_count(uaa-device, nifaces);
-   if (err)
-   return (UMATCH_NONE);
-   usbd_set_config_index(uaa-device, USB_UNCONFIG_INDEX, 1);
-   }
+   else
+   return UMATCH_NONE;

/* JTAG on USB interface 0 */
if (uaa-vendor == USB_VENDOR_FTDI 
-   uaa-product == USB_PRODUCT_FTDI_OPENRD 
+   (uaa-product == USB_PRODUCT_FTDI_OPENRD ||
+   uaa-product == USB_PRODUCT_FTDI_SERIAL_2232C) 
uaa-ifaceno == 0)
return (UMATCH_NONE);





uftdi baud rates

2012-09-20 Thread Raphael Graf
This diff is about the baud rate divisor calculation.
The driver should now support the full range of possible baud rates for
FT232BM and later devices.
(The calculation is described in the document AN_120 Aliasing VCP
Baud Rates from ftdi.)


Index: sys/dev/usb/uftdireg.h
===
RCS file: /cvs/src/sys/dev/usb/uftdireg.h,v
retrieving revision 1.13
diff -u -p -r1.13 uftdireg.h
--- sys/dev/usb/uftdireg.h  11 Sep 2012 16:04:44 -  1.13
+++ sys/dev/usb/uftdireg.h  20 Sep 2012 21:42:51 -
@@ -36,6 +36,7 @@
 enum uftdi_type {
UFTDI_TYPE_SIO,
UFTDI_TYPE_8U232AM,
+   UFTDI_TYPE_232BM,
UFTDI_TYPE_2232H
 };

Index: sys/dev/usb/uftdi.c
===
RCS file: /cvs/src/sys/dev/usb/uftdi.c,v
retrieving revision 1.63
diff -u -p -r1.63 uftdi.c
--- sys/dev/usb/uftdi.c 11 Sep 2012 16:04:44 -  1.63
+++ sys/dev/usb/uftdi.c 20 Sep 2012 21:42:52 -
@@ -105,7 +105,7 @@ voiduftdi_write(void *sc, int portno, u
u_int32_t *count);
 void   uftdi_break(void *sc, int portno, int onoff);
 intuftdi_8u232am_getrate(speed_t speed, int *rate);
-intuftdi_2232h_getrate(speed_t speed, int *rate);
+intuftdi_232bm_getrate(speed_t speed, int freq, int *rate);

 struct ucom_methods uftdi_methods = {
uftdi_get_status,
@@ -821,17 +821,19 @@ uftdi_attach(struct device *parent, stru

sc-sc_udev = dev;
sc-sc_iface = iface;
+   sc-sc_hdrlen = 0;

if (uaa-release  0x0200) {
sc-sc_type = UFTDI_TYPE_SIO;
sc-sc_hdrlen = 1;
-   } else if (uaa-release == 0x0700  || uaa-release == 0x0800) {
+   } else if (uaa-release  0x0500)
+   sc-sc_type = UFTDI_TYPE_8U232AM;
+   else if (uaa-release  0x0700)
+   sc-sc_type = UFTDI_TYPE_232BM;
+   else if (uaa-release  0x0A00)
sc-sc_type = UFTDI_TYPE_2232H;
-   sc-sc_hdrlen = 0;
-   } else {
+   else
sc-sc_type = UFTDI_TYPE_8U232AM;
-   sc-sc_hdrlen = 0;
-   }

uca.bulkin = uca.bulkout = -1;
for (i = 0; i  id-bNumEndpoints; i++) {
@@ -1083,9 +1085,19 @@ uftdi_param(void *vsc, int portno, struc
if (uftdi_8u232am_getrate(t-c_ospeed, rate) == -1)
return (EINVAL);
break;
+   case UFTDI_TYPE_232BM:
+   if (uftdi_232bm_getrate(t-c_ospeed, FTDI_8U232AM_FREQ, rate) 
== -1)
+   return (EINVAL);
case UFTDI_TYPE_2232H:
-   if (uftdi_2232h_getrate(t-c_ospeed, rate) == -1)
-return (EINVAL);
+   if (t-c_ospeed = FTDI_8U232AM_FREQ) {
+   if (uftdi_232bm_getrate(t-c_ospeed, FTDI_8U232AM_FREQ, 
rate) == -1)
+   return (EINVAL);
+   } else {
+   if (uftdi_232bm_getrate(t-c_ospeed, FTDI_2232H_FREQ, 
rate) == -1)
+   return (EINVAL);
+   /* Set this bit to turn off a divide by 2.5 */
+   rate|= 0x0002;
+   }
break;
}
req.bmRequestType = UT_WRITE_VENDOR_DEVICE;
@@ -1263,31 +1275,37 @@ done:
 }

 int
-uftdi_2232h_getrate(speed_t speed, int *rate)
+uftdi_232bm_getrate(speed_t speed, int freq, int *rate)
 {
char sub[8] = {0, 3, 2, 4, 1, 5, 6, 7};
-   int n = (FTDI_2232H_FREQ  3) / speed;
+   int n = ((freq  3) + (speed  1)) / speed;
int s = n  7;
-   int result = (n  3) | (sub[s]  14);
+   int resultint = (n  3);
+   int result = resultint | (sub[s]  14);
int resultspeed, accuracy;

/* Special cases */
-   if (result == 1)
-   result = 0;
-   else if (result == 0x4001)
+   if (resultint == 0 || resultint  16384)
+   return -1;
+   else if (speed  200 * 97 / 100  speed  200 * 103 / 100) {
result = 1;
+   goto done;
+   }
+   else if (resultint == 1) {
+   result = 0;
+   s = 0;
+   }

/* Check if resulting baud rate is within 3%. */
-   if (result == 0)
+   if (resultint == 0)
goto done;
-   resultspeed = (FTDI_2232H_FREQ  3) /
-   (((result  0x3FFF)  3) | s);
+   resultspeed = (freq  3) /
+   ((resultint  3) | s);
accuracy = (abs(speed - resultspeed) * 100) / speed;
-   if (accuracy  3)
+   if (accuracy = 3)
return -1;

 done:
-   result|= 0x0002; /* Set this bit to turn off a divide by 2.5 */
*rate = result;
return 0;
 }



FTDI FT2232H

2012-09-08 Thread Raphael Graf
This adds support for the FT2232H and FT4232H serial adapters.
(FT2232H found on the BeagleBone).

These devices have a 120MHz base clock for the baud rate generator
and need a different encoding for the baud rate divisor.
The values for ibufsize/obufsize are now taken from the endpoint descriptors.

I can't be sure that this does not break anything. It would have to be
tested on various devices.

Regards
Raphael


Index: sys/dev/usb/uftdireg.h
===
RCS file: /cvs/src/sys/dev/usb/uftdireg.h,v
retrieving revision 1.12
diff -u -p -r1.12 uftdireg.h
--- sys/dev/usb/uftdireg.h  5 Jul 2008 14:41:28 -   1.12
+++ sys/dev/usb/uftdireg.h  8 Sep 2012 14:32:13 -
@@ -35,7 +35,8 @@

 enum uftdi_type {
UFTDI_TYPE_SIO,
-   UFTDI_TYPE_8U232AM
+   UFTDI_TYPE_8U232AM,
+   UFTDI_TYPE_2232H
 };

 /*
@@ -91,7 +92,8 @@ enum {
ftdi_sio_b115200 = 9
 };

-#define FTDI_8U232AM_FREQ 300
+#define FTDI_8U232AM_FREQ 300 /* (48MHz / 16) */
+#define FTDI_2232H_FREQ 1200 /* (120MHz / 10) */

 /* Bounds for normal divisors as 4-bit fixed precision ints. */
 #define FTDI_8U232AM_MIN_DIV 0x20
Index: sys/dev/usb/uftdi.c
===
RCS file: /cvs/src/sys/dev/usb/uftdi.c,v
retrieving revision 1.62
diff -u -p -r1.62 uftdi.c
--- sys/dev/usb/uftdi.c 28 Oct 2011 01:45:55 -  1.62
+++ sys/dev/usb/uftdi.c 8 Sep 2012 14:32:14 -
@@ -105,6 +105,7 @@ voiduftdi_write(void *sc, int portno, u
u_int32_t *count);
 void   uftdi_break(void *sc, int portno, int onoff);
 intuftdi_8u232am_getrate(speed_t speed, int *rate);
+intuftdi_2232h_getrate(speed_t speed, int *rate);

 struct ucom_methods uftdi_methods = {
uftdi_get_status,
@@ -824,6 +825,9 @@ uftdi_attach(struct device *parent, stru
if (uaa-release  0x0200) {
sc-sc_type = UFTDI_TYPE_SIO;
sc-sc_hdrlen = 1;
+   } else if (uaa-release == 0x0700  || uaa-release == 0x0800) {
+   sc-sc_type = UFTDI_TYPE_2232H;
+   sc-sc_hdrlen = 0;
} else {
sc-sc_type = UFTDI_TYPE_8U232AM;
sc-sc_hdrlen = 0;
@@ -842,11 +846,16 @@ uftdi_attach(struct device *parent, stru
addr = ed-bEndpointAddress;
dir = UE_GET_DIR(ed-bEndpointAddress);
attr = ed-bmAttributes  UE_XFERTYPE;
-   if (dir == UE_DIR_IN  attr == UE_BULK)
+   if (dir == UE_DIR_IN  attr == UE_BULK) {
uca.bulkin = addr;
-   else if (dir == UE_DIR_OUT  attr == UE_BULK)
+   uca.ibufsize = (UGETW(ed-wMaxPacketSize)  0) ?
+   UGETW(ed-wMaxPacketSize) : UFTDIIBUFSIZE;
+   } else if (dir == UE_DIR_OUT  attr == UE_BULK) {
uca.bulkout = addr;
-   else {
+   uca.obufsize = (UGETW(ed-wMaxPacketSize)  0) ?
+   UGETW(ed-wMaxPacketSize) : UFTDIOBUFSIZE;
+   uca.obufsize-= sc-sc_hdrlen;
+   } else {
printf(%s: unexpected endpoint\n, devname);
goto bad;
}
@@ -867,9 +876,7 @@ uftdi_attach(struct device *parent, stru
else
uca.portno = FTDI_PIT_SIOA + id-bInterfaceNumber;
/* bulkin, bulkout set above */
-   uca.ibufsize = UFTDIIBUFSIZE;
-   uca.obufsize = UFTDIOBUFSIZE - sc-sc_hdrlen;
-   uca.ibufsizepad = UFTDIIBUFSIZE;
+   uca.ibufsizepad = uca.ibufsize;
uca.opkthdrlen = sc-sc_hdrlen;
uca.device = dev;
uca.iface = iface;
@@ -1076,11 +1083,15 @@ uftdi_param(void *vsc, int portno, struc
if (uftdi_8u232am_getrate(t-c_ospeed, rate) == -1)
return (EINVAL);
break;
+   case UFTDI_TYPE_2232H:
+   if (uftdi_2232h_getrate(t-c_ospeed, rate) == -1)
+return (EINVAL);
+   break;
}
req.bmRequestType = UT_WRITE_VENDOR_DEVICE;
req.bRequest = FTDI_SIO_SET_BAUD_RATE;
USETW(req.wValue, rate);
-   USETW(req.wIndex, portno);
+   USETW(req.wIndex, ((rate  8)  0xFF00) | portno);
USETW(req.wLength, 0);
DPRINTFN(2,(uftdi_param: reqtype=0x%02x req=0x%02x value=0x%04x 
index=0x%04x len=%d\n, req.bmRequestType, req.bRequest,
@@ -1249,4 +1260,34 @@ uftdi_8u232am_getrate(speed_t speed, int
 done:
*rate = result;
return (0);
+}
+
+int
+uftdi_2232h_getrate(speed_t speed, int *rate)
+{
+   char sub[8] = {0, 3, 2, 4, 1, 5, 6, 7};
+   int n = (FTDI_2232H_FREQ  3) / speed;
+   int s = n  7;
+   int result = (n  3) | (sub[s]  14);
+   int resultspeed, accuracy;
+
+   /* Special cases */
+   if (result == 1)
+   result = 0;
+   else if