Re: [PATCH] add boot option to control Intel combined mode behavior (to allow DMA in combined mode configs!)

[Jeff Garzik <jgarzik@pobox.com>]

Jesse Barnes wrote:
> Combined mode sucks.  Especially when both libata and the legacy IDE 
> drivers try to drive ports on the same device, since that makes DMA 
> rather difficult.
>
> This patch addresses the problem by allowing the user to control which 
> driver binds to the ports in a combined mode configuration.  In many 
> cases, they'll probably want the libata driver to control both ports 
> since it can use DMA for talking with ATAPI devices (when 
> libata.atapi_enabled=1 of course).  It also allows the user to get old 
> school behavior by letting the legacy IDE driver bind to both ports.  
> But neither is forced, the patch doesn't change current behavior unless 
> one of intel_combined_mode=ide or intel_combined_mode=libata is passed 
> on the boot line.  Either of those options may require you to access 
> your devices via different device nodes (/dev/hd* in the ide case 
> and /dev/sd* in the libata case), though of course if you have udev 
> installed nicely you may not notice anything. :)
>
> Let me know if the documentation is too cryptic, I'd be happy to expand 
> on it if necessary.  I think most users will want to boot with 
> 'intel_combined_mode=libata' and add 'options libata atapi_enabled=1' 
> to their modules.conf to get good DVD playing and disk behavior 
> (haven't tested CD or DVD writing though).
>
>  Documentation/kernel-parameters.txt |    7 +++++++
>  drivers/pci/quirks.c                |   30 ++++++++++++++++++++++++++++
>
> I'd much rather things behave sanely by default (i.e. DMA for devices on 
> both ports), but apparently that's difficult given the various chip 
> bugs and hardware configs out there (not to mention that people's 
> drives may suddenly change from /dev/hdc to /dev/sdb), so this boot 
> option may be the correct long term fix.
>
> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>

Seems like it should work.  I presume you tested this?

Remove the 'intel_' prefix from the kernel parameter, since this concept 
applies to other controllers as well.  Otherwise, seems OK.

	Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/