Re: sata_sil 3112 activity LED patch
On Fri, Jul 15, 2005 at 02:57PM +0900, Aric Cyr wrote: > Out of curiosity, did the LED > usage change at all before and after the patch, or was it totally > unaffected. I would guess the latter. It was totally unaffected. If the LED is turned on by the BIOS (while it examines the bus at boot time), it remains on as long as Linux is running. If it isn't turned on by the BIOS (Silicon Image's reference BIOS), it doesn't light up under Linux as well. > Thanks, I will. I have emailed Silicon Image in the (slim) chance > that they will provide me with the information I require. If they > come through then I might be able to whip something up and have you > test it. Thanks for looking into this! -- Christian Kroll <[EMAIL PROTECTED]> GnuPG Fingerprint: DA5D 5BFA 5C95 FD09 2A72 517E 10CB DCD5 71ED 7E35 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: sata_sil 3112 activity LED patch
On Fri, Jul 15, 2005 at 04:15:12AM +0200, Christian Kroll wrote: > I have tested the patch against my DawiControl DC-150 RAID controller > which is basically an add-on card with a SiI 3112 ASIC and a flash ROM. > The activity LED of my case is directly connected to the add-on card. > > Unfortunately your patch doesn't have any effect on the LED. The > activity LED gets turned on by the card's BIOS at boot time and > continues to shine until I shut down the computer. > On the other hand it did not erase my Flash ROM and I haven't spotted > any data loss so far. No data loss is a good thing! That was my biggest worry, as I have no documentation for the addon card case. Out of curiosity, did the LED usage change at all before and after the patch, or was it totally unaffected. I would guess the latter. Unfortunately, what documentation I do have shows (briefly) that add on cards implement their LED via a different mechanism. If I knew the addresses for the flash read and write strobes (FL_RDN and FL_WRN), I might be able to work something out. So as it stands, there is not much hope for the people with addon cards. > If you require more information, don't hesitate to contact me. Thanks, I will. I have emailed Silicon Image in the (slim) chance that they will provide me with the information I require. If they come through then I might be able to whip something up and have you test it. If anyone has any data on the 3112a (or 3512 as I believe they are register compatible) and isn't bound by an NDA, I'd like to hear from you. -- Aric Cyr (http://acyr.net) gpg fingerprint: 943A 1549 47AC D766 B7F8 D551 6703 7142 C282 D542 pgpfSBy3ao27E.pgp Description: PGP signature
Re: sata_sil 3112 activity LED patch
On Fri, Jul 15, 2005 at 04:15:12AM +0200, Christian Kroll wrote: I have tested the patch against my DawiControl DC-150 RAID controller which is basically an add-on card with a SiI 3112 ASIC and a flash ROM. The activity LED of my case is directly connected to the add-on card. Unfortunately your patch doesn't have any effect on the LED. The activity LED gets turned on by the card's BIOS at boot time and continues to shine until I shut down the computer. On the other hand it did not erase my Flash ROM and I haven't spotted any data loss so far. No data loss is a good thing! That was my biggest worry, as I have no documentation for the addon card case. Out of curiosity, did the LED usage change at all before and after the patch, or was it totally unaffected. I would guess the latter. Unfortunately, what documentation I do have shows (briefly) that add on cards implement their LED via a different mechanism. If I knew the addresses for the flash read and write strobes (FL_RDN and FL_WRN), I might be able to work something out. So as it stands, there is not much hope for the people with addon cards. If you require more information, don't hesitate to contact me. Thanks, I will. I have emailed Silicon Image in the (slim) chance that they will provide me with the information I require. If they come through then I might be able to whip something up and have you test it. If anyone has any data on the 3112a (or 3512 as I believe they are register compatible) and isn't bound by an NDA, I'd like to hear from you. -- Aric Cyr acyr at alumni dot uwaterloo dot ca(http://acyr.net) gpg fingerprint: 943A 1549 47AC D766 B7F8 D551 6703 7142 C282 D542 pgpfSBy3ao27E.pgp Description: PGP signature
Re: sata_sil 3112 activity LED patch
On Fri, Jul 15, 2005 at 02:57PM +0900, Aric Cyr wrote: Out of curiosity, did the LED usage change at all before and after the patch, or was it totally unaffected. I would guess the latter. It was totally unaffected. If the LED is turned on by the BIOS (while it examines the bus at boot time), it remains on as long as Linux is running. If it isn't turned on by the BIOS (Silicon Image's reference BIOS), it doesn't light up under Linux as well. Thanks, I will. I have emailed Silicon Image in the (slim) chance that they will provide me with the information I require. If they come through then I might be able to whip something up and have you test it. Thanks for looking into this! -- Christian Kroll [EMAIL PROTECTED] GnuPG Fingerprint: DA5D 5BFA 5C95 FD09 2A72 517E 10CB DCD5 71ED 7E35 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: sata_sil 3112 activity LED patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I have tested the patch against my DawiControl DC-150 RAID controller which is basically an add-on card with a SiI 3112 ASIC and a flash ROM. The activity LED of my case is directly connected to the add-on card. Unfortunately your patch doesn't have any effect on the LED. The activity LED gets turned on by the card's BIOS at boot time and continues to shine until I shut down the computer. On the other hand it did not erase my Flash ROM and I haven't spotted any data loss so far. The LED does work as expected under that other OS as soon as Silicon Image's reference driver is loaded, hence it is connected correctly. Test setup: I'm using DawiControl's version of the BIOS and not the reference BIOS of Silicon Image. The test system is a Tualatin Celeron 1400 with an i440BX based mainboard. The following hard disk is connected to the controller: Seagate ST3160827AS (native SATA interface). The sata_sil driver is loaded as a module. Test kernel is vanilla 2.6.12.2. No tainted modules were used while doing these tests. If you require more information, don't hesitate to contact me. Regards Christian Kroll - -- Christian Kroll GnuPG Fingerprint: DA5D 5BFA 5C95 FD09 2A72 517E 10CB DCD5 71ED 7E35 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC1xsQEMvc1XHtfjURAqKQAJ0fp5EtdymeUsiklcqYsCR9Q7VyngCeIfKV Sb/wTjlvfk6MPMk/KEBkBPY= =g7Vc -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata_sil 3112 activity LED patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I have tested the patch against my DawiControl DC-150 RAID controller which is basically an add-on card with a SiI 3112 ASIC and a flash ROM. The activity LED of my case is directly connected to the add-on card. Unfortunately your patch doesn't have any effect on the LED. The activity LED gets turned on by the card's BIOS at boot time and continues to shine until I shut down the computer. On the other hand it did not erase my Flash ROM and I haven't spotted any data loss so far. The LED does work as expected under that other OS as soon as Silicon Image's reference driver is loaded, hence it is connected correctly. Test setup: I'm using DawiControl's version of the BIOS and not the reference BIOS of Silicon Image. The test system is a Tualatin Celeron 1400 with an i440BX based mainboard. The following hard disk is connected to the controller: Seagate ST3160827AS (native SATA interface). The sata_sil driver is loaded as a module. Test kernel is vanilla 2.6.12.2. No tainted modules were used while doing these tests. If you require more information, don't hesitate to contact me. Regards Christian Kroll - -- Christian Kroll christian dot kroll at bglug dot org GnuPG Fingerprint: DA5D 5BFA 5C95 FD09 2A72 517E 10CB DCD5 71ED 7E35 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC1xsQEMvc1XHtfjURAqKQAJ0fp5EtdymeUsiklcqYsCR9Q7VyngCeIfKV Sb/wTjlvfk6MPMk/KEBkBPY= =g7Vc -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata_sil 3112 activity LED patch
On Thu, Jul 07 2005, Aric Cyr wrote: > > There's also an existing variant of this in the block layer, the > > activity_fn, that we use on the ibook/powerbook to use the sleep led as > > an activity light. Just in case you prefer that to overloading the bmdma > > start/stop handlers. > > You suggestion at first looked to be incredibly nice... until I looked > at how much implementation was required. I am considering trying it, > but I cannot find a place for an sata driver to call the > blk_queue_activity_fn() with meaningful parameters during init. > > On a second look, I guess I would have to override > ata_scsi_slave_config() in the driver and hook up the activity light > there. This would be fine I guess. Unless I am interpreting this > incorrectly, however, I would need to use a timer or something to turn > the light back off? I'm probably missing something, so is there a > simpler way to do this? Hmm yes, it will require more work for you. It should be cleaned up a little to pass in a START/STOP variable and handle everything in the block layer instead. You probably just want to continue using the bmdma hooks now, that is actually a fine implementation imo. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata_sil 3112 activity LED patch
On Wed, Jul 06 2005, Jeff Garzik wrote: > Aric Cyr wrote: > >After finally getting fed up with not having my activity light working > >for my SATA drives, I came up with a small patch (more like hack) to > >make it work. It works quite well, but I'm afraid that there are many > >restriction that this patch does not check for that it probably > >should... so consider this a work-in-progress. My information is > >based on a document from Silicon Image that appears to no longer be > >available on their website (Sil-AN-0082-E; 8112-0082.pdf). I still > >have a copy if anyone is interested. > > > >There are two restrictions that are not checked: > > > >1) Is the chip a 3112 or 3114? I assume that this would only work on > > a 3112, but whether it is "a bad thing" on a 3114 I do not know. > > > >2) BAR5 + 0x54 is apparently used for the flash memory address and > > data lines. However for most motherboards (i.e. not add-on cards) > > with the chip, like my EPOX 8RDA3+, there is no flash memory, so > > these lines are hijacked as LED GPIO. I assume that this is a > > common practice for motherboard makers using the sil3112 since > > Silicon Image went out of their way to produce the above mentioned > > document. Anyways, the problem is that this patch does not check > > if flash memory is installed or not before twiddling with the GPIO > > lines. This could be extremely bad for people running the 3112 > > from add-on cards (or any implementation with flash memory > > installed). > > > >Setting the low 8bits at BAR5+54h seems to enable the LED circuit. It > >seems that this circuit is patched through into the motherboard as it > >lights the regular hard drive light on the front of my case. Setting > >bits [8:15] at BAR5+54h clears the bits, disabling the LED. I hooked > >this logic into the ata_bmdma_start and ata_bmdma_stop which were made > >into simple wrapper functions in sata_sil.c that just set the GPIO > >bits and calls ata_bmdma_*. > > I don't think its ugly, necessarily. I do worry about the flash memory > stuff, though, which is why I don't want to merge this upstream for now. > > For your patch specifically, it would be nice to follow the coding style > that is found in the rest of the driver (single-tab indents, etc., read > CodingStyle in kernel source tree). There's also an existing variant of this in the block layer, the activity_fn, that we use on the ibook/powerbook to use the sleep led as an activity light. Just in case you prefer that to overloading the bmdma start/stop handlers. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata_sil 3112 activity LED patch
On Wed, Jul 06 2005, Jeff Garzik wrote: Aric Cyr wrote: After finally getting fed up with not having my activity light working for my SATA drives, I came up with a small patch (more like hack) to make it work. It works quite well, but I'm afraid that there are many restriction that this patch does not check for that it probably should... so consider this a work-in-progress. My information is based on a document from Silicon Image that appears to no longer be available on their website (Sil-AN-0082-E; 8112-0082.pdf). I still have a copy if anyone is interested. There are two restrictions that are not checked: 1) Is the chip a 3112 or 3114? I assume that this would only work on a 3112, but whether it is a bad thing on a 3114 I do not know. 2) BAR5 + 0x54 is apparently used for the flash memory address and data lines. However for most motherboards (i.e. not add-on cards) with the chip, like my EPOX 8RDA3+, there is no flash memory, so these lines are hijacked as LED GPIO. I assume that this is a common practice for motherboard makers using the sil3112 since Silicon Image went out of their way to produce the above mentioned document. Anyways, the problem is that this patch does not check if flash memory is installed or not before twiddling with the GPIO lines. This could be extremely bad for people running the 3112 from add-on cards (or any implementation with flash memory installed). Setting the low 8bits at BAR5+54h seems to enable the LED circuit. It seems that this circuit is patched through into the motherboard as it lights the regular hard drive light on the front of my case. Setting bits [8:15] at BAR5+54h clears the bits, disabling the LED. I hooked this logic into the ata_bmdma_start and ata_bmdma_stop which were made into simple wrapper functions in sata_sil.c that just set the GPIO bits and calls ata_bmdma_*. I don't think its ugly, necessarily. I do worry about the flash memory stuff, though, which is why I don't want to merge this upstream for now. For your patch specifically, it would be nice to follow the coding style that is found in the rest of the driver (single-tab indents, etc., read CodingStyle in kernel source tree). There's also an existing variant of this in the block layer, the activity_fn, that we use on the ibook/powerbook to use the sleep led as an activity light. Just in case you prefer that to overloading the bmdma start/stop handlers. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata_sil 3112 activity LED patch
On Thu, Jul 07 2005, Aric Cyr wrote: There's also an existing variant of this in the block layer, the activity_fn, that we use on the ibook/powerbook to use the sleep led as an activity light. Just in case you prefer that to overloading the bmdma start/stop handlers. You suggestion at first looked to be incredibly nice... until I looked at how much implementation was required. I am considering trying it, but I cannot find a place for an sata driver to call the blk_queue_activity_fn() with meaningful parameters during init. On a second look, I guess I would have to override ata_scsi_slave_config() in the driver and hook up the activity light there. This would be fine I guess. Unless I am interpreting this incorrectly, however, I would need to use a timer or something to turn the light back off? I'm probably missing something, so is there a simpler way to do this? Hmm yes, it will require more work for you. It should be cleaned up a little to pass in a START/STOP variable and handle everything in the block layer instead. You probably just want to continue using the bmdma hooks now, that is actually a fine implementation imo. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata_sil 3112 activity LED patch
Aric Cyr wrote: After finally getting fed up with not having my activity light working for my SATA drives, I came up with a small patch (more like hack) to make it work. It works quite well, but I'm afraid that there are many restriction that this patch does not check for that it probably should... so consider this a work-in-progress. My information is based on a document from Silicon Image that appears to no longer be available on their website (Sil-AN-0082-E; 8112-0082.pdf). I still have a copy if anyone is interested. There are two restrictions that are not checked: 1) Is the chip a 3112 or 3114? I assume that this would only work on a 3112, but whether it is "a bad thing" on a 3114 I do not know. 2) BAR5 + 0x54 is apparently used for the flash memory address and data lines. However for most motherboards (i.e. not add-on cards) with the chip, like my EPOX 8RDA3+, there is no flash memory, so these lines are hijacked as LED GPIO. I assume that this is a common practice for motherboard makers using the sil3112 since Silicon Image went out of their way to produce the above mentioned document. Anyways, the problem is that this patch does not check if flash memory is installed or not before twiddling with the GPIO lines. This could be extremely bad for people running the 3112 from add-on cards (or any implementation with flash memory installed). Setting the low 8bits at BAR5+54h seems to enable the LED circuit. It seems that this circuit is patched through into the motherboard as it lights the regular hard drive light on the front of my case. Setting bits [8:15] at BAR5+54h clears the bits, disabling the LED. I hooked this logic into the ata_bmdma_start and ata_bmdma_stop which were made into simple wrapper functions in sata_sil.c that just set the GPIO bits and calls ata_bmdma_*. I don't think its ugly, necessarily. I do worry about the flash memory stuff, though, which is why I don't want to merge this upstream for now. For your patch specifically, it would be nice to follow the coding style that is found in the rest of the driver (single-tab indents, etc., read CodingStyle in kernel source tree). Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata_sil 3112 activity LED patch
Aric Cyr wrote: After finally getting fed up with not having my activity light working for my SATA drives, I came up with a small patch (more like hack) to make it work. It works quite well, but I'm afraid that there are many restriction that this patch does not check for that it probably should... so consider this a work-in-progress. My information is based on a document from Silicon Image that appears to no longer be available on their website (Sil-AN-0082-E; 8112-0082.pdf). I still have a copy if anyone is interested. There are two restrictions that are not checked: 1) Is the chip a 3112 or 3114? I assume that this would only work on a 3112, but whether it is a bad thing on a 3114 I do not know. 2) BAR5 + 0x54 is apparently used for the flash memory address and data lines. However for most motherboards (i.e. not add-on cards) with the chip, like my EPOX 8RDA3+, there is no flash memory, so these lines are hijacked as LED GPIO. I assume that this is a common practice for motherboard makers using the sil3112 since Silicon Image went out of their way to produce the above mentioned document. Anyways, the problem is that this patch does not check if flash memory is installed or not before twiddling with the GPIO lines. This could be extremely bad for people running the 3112 from add-on cards (or any implementation with flash memory installed). Setting the low 8bits at BAR5+54h seems to enable the LED circuit. It seems that this circuit is patched through into the motherboard as it lights the regular hard drive light on the front of my case. Setting bits [8:15] at BAR5+54h clears the bits, disabling the LED. I hooked this logic into the ata_bmdma_start and ata_bmdma_stop which were made into simple wrapper functions in sata_sil.c that just set the GPIO bits and calls ata_bmdma_*. I don't think its ugly, necessarily. I do worry about the flash memory stuff, though, which is why I don't want to merge this upstream for now. For your patch specifically, it would be nice to follow the coding style that is found in the rest of the driver (single-tab indents, etc., read CodingStyle in kernel source tree). Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
