On 2/5/07, Alan <[EMAIL PROTECTED]> wrote:
> Since we are already using UDMA mode set by BIOS to determine if 80c cable
> is present so why not also use it to determine if the 40c cable is present?
>
> I mean just ignoring AMD_CABLE_DETECT register for NVIDIA devices.
>
> 2-lines change and we wo
> Since we are already using UDMA mode set by BIOS to determine if 80c cable
> is present so why not also use it to determine if the 40c cable is present?
>
> I mean just ignoring AMD_CABLE_DETECT register for NVIDIA devices.
>
> 2-lines change and we wouldn't have to deal with ACPI at ell.
And
Alan wrote:
Well we can certainly do some of that if ACPI is present and active. In
particular since _GTM will give us current modes allowing for hotplug and
post BIOS boot kexec etc it ought to be safe to do Tejun's hack that way.
We could even probe UDMA3+ capable devices by doing _STM to a hig
On 2/5/07, Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
> > Well we can certainly do some of that if ACPI is present and active. In
> > particular since _GTM will give us current modes allowing for hotplug and
> > post BIOS boot kexec etc it ought to be safe to do Tejun's hack that way.
>
Bartlomiej Zolnierkiewicz wrote:
> Hi,
>
> On 2/5/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
>> Alan wrote:
>> >> The *real* solution is to use the BIOS ACPI _GTM _STM methods for
>> this.
>> >> Then you can remove all chipset specific knowledge from the IDE
>> driver.
>> >> This is what the MS driv
> > Well we can certainly do some of that if ACPI is present and active. In
> > particular since _GTM will give us current modes allowing for hotplug and
> > post BIOS boot kexec etc it ought to be safe to do Tejun's hack that way.
> > We could even probe UDMA3+ capable devices by doing _STM to a h
Hi,
On 2/5/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
Alan wrote:
>> The *real* solution is to use the BIOS ACPI _GTM _STM methods for this.
>> Then you can remove all chipset specific knowledge from the IDE driver.
>> This is what the MS driver does on Windows, so you know it's received a
>> lot
Alan wrote:
>> The *real* solution is to use the BIOS ACPI _GTM _STM methods for this.
>> Then you can remove all chipset specific knowledge from the IDE driver.
>> This is what the MS driver does on Windows, so you know it's received a
>> lot of testing from NVIDIA and board vendors.
>
> Well we
> The *real* solution is to use the BIOS ACPI _GTM _STM methods for this.
> Then you can remove all chipset specific knowledge from the IDE driver.
> This is what the MS driver does on Windows, so you know it's received a
> lot of testing from NVIDIA and board vendors.
Well we can certainly do som
>
> Date: Feb 5, 2007 3:50 PM
> Subject: Re: Nvidia cable detection problems (was [PATCH] amd74xx:
> don't configure udma mode higher than BIOS did)
> To: Alan <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], linux-ide@vger.kernel.org,
> linux-kernel@vger.kerne
> > No the IDE layer does DMA changedown fine, well apart from all the
> > error/timer races in the old IDE code.
>
> I dunno. It always ended up in PIO mode in my case. I can post the log
> if necessary.
Ok testing my hardware
- AMD get it right for those with host cable detect
- AMD get it r
Tejun Heo wrote:
CK804 IDE, at least mine, reports 80c in a lot of cases where it
shouldn't. I dunno the reason but it also makes drives confused about
cable type. Maybe it has the wrong capacitor attached or something.
This is A8N-E from ASUS, probably one of the popular ones using nf4.
Wh
Alan wrote:
[--snip--]
>> CK804 IDE, at least mine, reports 80c in a lot of cases where it
>> shouldn't. I dunno the reason but it also makes drives confused about
>> cable type. Maybe it has the wrong capacitor attached or something.
>> This is A8N-E from ASUS, probably one of the popular ones u
> > Also another case you broke is kexec.
>
> 1. If kexec is done while either of amd74xx or pata_amd is loaded, the
> currently configured mode is what the kexeced kernel would use as
> reference. If the port has been slowed down during operation, yeah, it
> would be sub-optimal but again the wo
Alan wrote:
>> To prevent that, the value is cached on driver probe and written back on
>> driver detach on pata_amd, which is necessary even when there is no
>
> Which is useless.
I can agree to 'not always effective' but its useful in common driver
load/unload cases.
>> suspend/resume as mode
Alan wrote:
> You get whatever the chip has loaded. The BIOS may pick PIO modes only,
In that case, the code does NOT apply. All the code does is applying at
most UDMA33 limit if BIOS has configured && enabled UDMA mode.
> the BIOS may not have been run so the UDMA bits could be arbitary. You
>
> To prevent that, the value is cached on driver probe and written back on
> driver detach on pata_amd, which is necessary even when there is no
Which is useless.
> suspend/resume as mode programming alters the content of the register.
> amd74xx cannot be unloaded, so caching is enough. Also, do
> If BIOS hasn't run, UDMA timing wouldn't have been programmed and as
> such the speed won't be limited. So, there should be no harm done in
> that case. Even if something goes really wrong, the worst happens is
> capping speed to udma33.
Which is bad and leaves people with mysterious performan
Forgot to reply about some stuff. Adding.
Tejun Heo wrote:
> Alan wrote:
>>> This patch makes amd74xx not configure udma mode higher than BIOS did.
>>> If BIOS configured the device <= udma44, udma33 is the maximum speed.
>> NAK
>>
>> The boot firmware for AMD/Nvidia chips is only run on PC, and
Alan wrote:
>> This patch makes amd74xx not configure udma mode higher than BIOS did.
>> If BIOS configured the device <= udma44, udma33 is the maximum speed.
>
> NAK
>
> The boot firmware for AMD/Nvidia chips is only run on PC, and the data is
> only valid on some of them, in some cases, and not
> This patch makes amd74xx not configure udma mode higher than BIOS did.
> If BIOS configured the device <= udma44, udma33 is the maximum speed.
NAK
The boot firmware for AMD/Nvidia chips is only run on PC, and the data is
only valid on some of them, in some cases, and not after a suspend/resume
On many nvidia boards, BIOSen often set CABLE bit in EIDE Controller
Configuration Register even when 40c cable is attached but configures
transfer mode correctly (<= udma33). As amd74xx depends on the CABLE
bit to determine the cable type and thus the highest allowed udma
mode, this often results
22 matches
Mail list logo
