|
osdir.com mailing list archive |
|
Subject: RE: Re: Forward-Port of USB Disk Activity Blinking Code - msg#00097List: misc.nslu2.devel>I think the neatest solution from the PoV of apps using the devices would be to >have 1 fs entry per LED with 4 states, on, off, slow flash and fast flash where >the flashing was implemented by the driver which ensured the flashing was >synced. I thought about that but I don't like it for several reasons: 1) I want to be able to vary the flash rate. 2) I don't want the flashing in the kernel. That just doesn't seem to fit with the general Linux kernel design (udev, hotplug and so on). Synchronous flashing implies a shared time time. The current implementation doesn't have this - that's why leds has the -A option - it's really a work round for the fact that separate leds commands produce really weird/disturbing results. As soon as there is a shared time line I figure there is one device... John Bowler <jbowler-HInyCGIudOg@xxxxxxxxxxxxxxxx> >I realise my view doesn't count for much as I've only done Optware bits on the >slug so far and this suggestion is probably the most work for the kernel devs so >feel free to ignore. No, wrong, kernel developer views don't count, app writer views (and user views) do. It's pointless having the XScale GPIO design drive the device driver design - it doesn't matter how it is structured within the kernel. The appearance of the box is what matters (e.g. the fact that two LEDs are combined into what is apparently one light), along with how app writers need to use it. Remember that, since it is a shared resource it needs some kind of protocol to manage use by separate apps. For that reason I favour having a daemon and that daemon can certainly offer richer interfaces. I think it's also essential that the LEDs be scriptable. Still this could be done without a daemon, even using separate dev entries with different permissions. John Bowler <jbowler-HInyCGIudOg@xxxxxxxxxxxxxxxx> ------------------------ Yahoo! Groups Sponsor --------------------~--> Most low income households are not online. Help bridge the digital divide today! http://us.click.yahoo.com/cd_AJB/QnQLAA/TtwFAA/CFFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/nslu2-developers/ <*> To unsubscribe from this group, send an email to: nslu2-developers-unsubscribe-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ Thread at a glance:
Previous Message by Date: click to view message previewRe: Forward-Port of USB Disk Activity Blinking CodeJohn Bowler <jbowler@...> writes: > > That doesn't work because of the synchronisation issue - we need to be able > to control both the red and green ready/status lights simultaneously or very > weird flashing results. It seems to me that there is a very strong human > factors argument that normal flashing of the four LEDs should be > synchronised - the alternative may be useful for alerts but is extremely > distracting. Thus the set of four LEDs are a single device. I'm not sure > about the power and reset buttons. > I think the neatest solution from the PoV of apps using the devices would be to have 1 fs entry per LED with 4 states, on, off, slow flash and fast flash where the flashing was implemented by the driver which ensured the flashing was synced. The only thing I'm not sure about is the ready / status LED as to whether this should have 1 or 2 devices - I think one for the green half and one for the red half is best but in that case the flashing states need to define flash on/off and flash off/on so you can get both orange flashing and alternating red/green. For consistency you'd probably have the other states in the Disk LEDs too. I realise my view doesn't count for much as I've only done Optware bits on the slug so far and this suggestion is probably the most work for the kernel devs so feel free to ignore. ------------------------ Yahoo! Groups Sponsor --------------------~--> Fair play? Video games influencing politics. Click and talk back! http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/CFFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/nslu2-developers/ <*> To unsubscribe from this group, send an email to: nslu2-developers-unsubscribe-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ Next Message by Date: click to view message preview10-ixp4xx-copy-from.patchHere's a reworked version of the patch. The original version used 'get_unaligned' to deal with the fact that the API can get called to read bytes from an odd address - this would cause alignment faults. The original patch defeated the point of the routine because get_unaligned does 8 bit accesses. This version does (only) 16 bit access. (Take care, I suspect this mailer can insert ^Ms into text file attachments...) John Bowler <jbowler-HInyCGIudOg@xxxxxxxxxxxxxxxx> ------------------------ Yahoo! Groups Sponsor --------------------~--> Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/CFFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/nslu2-developers/ <*> To unsubscribe from this group, send an email to: nslu2-developers-unsubscribe-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ 10-ixp4xx-copy-from.patch Description: Binary data Previous Message by Thread: click to view message previewRe: Forward-Port of USB Disk Activity Blinking CodeJohn Bowler <jbowler@...> writes: > > That doesn't work because of the synchronisation issue - we need to be able > to control both the red and green ready/status lights simultaneously or very > weird flashing results. It seems to me that there is a very strong human > factors argument that normal flashing of the four LEDs should be > synchronised - the alternative may be useful for alerts but is extremely > distracting. Thus the set of four LEDs are a single device. I'm not sure > about the power and reset buttons. > I think the neatest solution from the PoV of apps using the devices would be to have 1 fs entry per LED with 4 states, on, off, slow flash and fast flash where the flashing was implemented by the driver which ensured the flashing was synced. The only thing I'm not sure about is the ready / status LED as to whether this should have 1 or 2 devices - I think one for the green half and one for the red half is best but in that case the flashing states need to define flash on/off and flash off/on so you can get both orange flashing and alternating red/green. For consistency you'd probably have the other states in the Disk LEDs too. I realise my view doesn't count for much as I've only done Optware bits on the slug so far and this suggestion is probably the most work for the kernel devs so feel free to ignore. ------------------------ Yahoo! Groups Sponsor --------------------~--> Fair play? Video games influencing politics. Click and talk back! http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/CFFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/nslu2-developers/ <*> To unsubscribe from this group, send an email to: nslu2-developers-unsubscribe-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ Next Message by Thread: click to view message previewRe: Re: Forward-Port of USB Disk Activity Blinking CodeOn Tue, Sep 20, 2005 at 02:15:08AM +0200, Øyvind Repvik wrote: > The relevant lines are: > > if (*udev->devpath == 0x31) { > *IXP4XX_GPIO_GPOUTR &= DISK1_ON; > } else (*udev->devpath == 0x32) { > *IXP4XX_GPIO_GPOUTR &= DISK2_ON; > } Please use the gpio_set_line (iirc) helper instead of directly twiddling the GPIO registers. cheers, Lennert ------------------------ Yahoo! Groups Sponsor --------------------~--> Most low income households are not online. Help bridge the digital divide today! http://us.click.yahoo.com/cd_AJB/QnQLAA/TtwFAA/CFFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/nslu2-developers/ <*> To unsubscribe from this group, send an email to: nslu2-developers-unsubscribe-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ Loading Comments...
|
|
