Re: Re HDMI transmitter interface

2014-09-22 Thread Manuel Bouyer
On Mon, Sep 22, 2014 at 07:15:00PM +0100, Robert Swindells wrote: > > Manuel Bouyer wrote: > >I made some progress on the TDA19988 HDMI transmitter driver as > >found in the beaglebone black (doens't work yet, sorry :). > >The driver will attach directly to the i2c bus, because other > >devices ar

Re: HDMI transmitter interface

2014-09-22 Thread Manuel Bouyer
On Mon, Sep 22, 2014 at 01:31:04PM -0300, Jared McNeill wrote: > On Mon, 22 Sep 2014, Manuel Bouyer wrote: > > /* > >* data we got from the monitor. Can be filled either by the > >* transmitter or the controller driver > >*/ > > uint8_t vdt_edid_data[128]

Re HDMI transmitter interface

2014-09-22 Thread Robert Swindells
Manuel Bouyer wrote: >I made some progress on the TDA19988 HDMI transmitter driver as >found in the beaglebone black (doens't work yet, sorry :). >The driver will attach directly to the i2c bus, because other >devices are also connected to this bus (eeprom, the power managenent IC, and >more depen

Re: Unification of common date/time macros

2014-09-22 Thread Kamil Rytarowski
Hello, Good point with reducing the (U)L modifiers, also reducing possible side-effects of 16-bit int, so going for 86400 explicitly is a good idea. I've already proposed patches with this bug-report: http://mail-index.netbsd.org/netbsd-bugs/2014/09/16/msg038315.html My idea was to extract verb

Re: HDMI transmitter interface

2014-09-22 Thread Jared McNeill
On Mon, 22 Sep 2014, Manuel Bouyer wrote: /* * data we got from the monitor. Can be filled either by the * transmitter or the controller driver */ uint8_t vdt_edid_data[128]; struct edid_info vdt_edid_info; Maybe change this a bit to make roo

HDMI transmitter interface

2014-09-22 Thread Manuel Bouyer
Hello, I made some progress on the TDA19988 HDMI transmitter driver as found in the beaglebone black (doens't work yet, sorry :). The driver will attach directly to the i2c bus, because other devices are also connected to this bus (eeprom, the power managenent IC, and more depending on connected ca

Re: Unification of common date/time macros

2014-09-22 Thread Alan Barrett
On Mon, 22 Sep 2014, Robert Elz wrote: | My proposition is [...] | | #define SECSPERMIN 60L | #define MINSPERHOUR 60L | #define HOURSPERDAY 24L | #define DAYSPERWEEK 7L | #define DAYSPERNYEAR365L | #define DAYSPERLYEAR366L | #define SECSPERHOUR (SECSPERMIN *

Re: Unification of common date/time macros

2014-09-22 Thread Christos Zoulas
In article <20140922053054.gb25...@netbsd.org>, David Holland wrote: >On Tue, Sep 16, 2014 at 01:37:11AM +0200, Kamil Rytarowski wrote: > > My proposition is to go for a new file src/sys/sys/clock.h. Normalize >naming with /usr/include/tzfile.h, then uniformly export the file for >reuse across th

Re: How PUFFS should deal with EDQUOT?

2014-09-22 Thread Emmanuel Dreyfus
Antti Kantee wrote: > I'd guess the key to success would be to support genfs_ops in puffs so > that the file server is consulted about block allocations. You mean gop_alloc() ? Is it documented somewhere? That would ease its implementation. If I understand correctly, that would be called when t

Re: Unification of common date/time macros

2014-09-22 Thread Robert Elz
Date:Tue, 16 Sep 2014 01:37:11 +0200 From:"Kamil Rytarowski" Message-ID: | My proposition is [...] | | #define SECSPERMIN 60L | #define MINSPERHOUR 60L | #define HOURSPERDAY 24L | #define DAYSPERWEEK 7L | #define DAYSPERNYEAR365L

Re: How NFS keeps state for getdents()?

2014-09-22 Thread Emmanuel Dreyfus
On Mon, Sep 22, 2014 at 05:38:14AM +, David Holland wrote: > Providing stable (or even correct) directory iteration is a Problem > and there is no particularly good solution. Some file systems > (eg. xfs) have gone to fairly substantial trouble to try to make this > work. That means that if I