Hi!
I have written a rough code skeleton to be able to use the ITE IT8716F
Super I/O chip as SPI host/master. The code works fine in userspace, but
the Linux kernel SPI framework looks like it could save me from
implementing full support for SPI flash clients/slaves. That's why I'd
like to
Hi!
I have written a rough code skeleton to be able to use the ITE IT8716F
Super I/O chip as SPI host/master. The code works fine in userspace, but
the Linux kernel SPI framework looks like it could save me from
implementing full support for SPI flash clients/slaves. That's why I'd
like to
Hi,
when compiling 2.6.23-rc7-git3 with a config which resembles
allmodconfig, I get the following warning in modpost:
WARNING: Can't handle masks in drivers/mtd/nand/cafe_nand:0
Regards,
Carl-Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Hi,
when compiling 2.6.23-rc7-git3 with a config which resembles
allmodconfig, I get the following warning in modpost:
WARNING: Can't handle masks in drivers/mtd/nand/cafe_nand:0
Regards,
Carl-Daniel
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
On 02.08.2007 13:33, Kay Sievers wrote:
> On 7/31/07, Kay Sievers <[EMAIL PROTECTED]> wrote:
>> On 7/31/07, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote:
>>> On 31.07.2007 00:17, Gabriel C wrote:
>>>> Sasa Ostrouska wrote:
>>>>
>
On 02.08.2007 13:33, Kay Sievers wrote:
On 7/31/07, Kay Sievers [EMAIL PROTECTED] wrote:
On 7/31/07, Carl-Daniel Hailfinger [EMAIL PROTECTED] wrote:
On 31.07.2007 00:17, Gabriel C wrote:
Sasa Ostrouska wrote:
Gabriel, hmm, shouldnt udev be able to autoconfigure that ? But I need
to check
On 31.07.2007 00:17, Gabriel C wrote:
> Sasa Ostrouska wrote:
>
>> Gabriel, hmm, shouldnt udev be able to autoconfigure that ? But I need
>> to check that, thx for the tip.
>
> Yes udev does this based on the MAC address but AFAIK forcedeth is 'special'
> for some reason
> ( which I can really
On 31.07.2007 00:17, Gabriel C wrote:
Sasa Ostrouska wrote:
Gabriel, hmm, shouldnt udev be able to autoconfigure that ? But I need
to check that, thx for the tip.
Yes udev does this based on the MAC address but AFAIK forcedeth is 'special'
for some reason
( which I can really remember
Hi,
On 08.03.2007 14:48, Russell King wrote:
> As I've said already, having a console on the same port as your application
> program is just asking for trouble. All bets are off - the kernel _will_
> corrupt your data stream in random places.
>
> Don't do it - it will _NEVER_ be reliable.
>
>
Hi,
On 08.03.2007 14:48, Russell King wrote:
As I've said already, having a console on the same port as your application
program is just asking for trouble. All bets are off - the kernel _will_
corrupt your data stream in random places.
Don't do it - it will _NEVER_ be reliable.
Never,
Andrew Morton wrote:
> On Fri, 9 Feb 2007 19:37:53 +
> Alan <[EMAIL PROTECTED]> wrote:
>
>> Please just push the EDAC K8 stuff.
>
> OK.
>
>> Andi will say "no" from now until the
>> end of time, but end users want it, distributions want it, and Andi is
>> not the EDAC maintainer so should
Andrew Morton wrote:
On Fri, 9 Feb 2007 19:37:53 +
Alan [EMAIL PROTECTED] wrote:
Please just push the EDAC K8 stuff.
OK.
Andi will say no from now until the
end of time, but end users want it, distributions want it, and Andi is
not the EDAC maintainer so should consider himself
Hi,
upon insertion of my new 2048 MB usb flash drive, the kernel
(vanilla 2.6.13) spat out the following errors:
usb 4-2: new high speed USB device using ehci_hcd and address 7
scsi1 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 7
usb-storage: waiting for device to
Hi,
upon insertion of my new 2048 MB usb flash drive, the kernel
(vanilla 2.6.13) spat out the following errors:
usb 4-2: new high speed USB device using ehci_hcd and address 7
scsi1 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 7
usb-storage: waiting for device to
Alan Stern schrieb:
> On Tue, 16 Aug 2005, Carl-Daniel Hailfinger wrote:
>
>
>>Hi,
>>[...]
>>Besides that, a number of drivers do not restore the pci config
>>space of their associated devices properly on resume from S3.
>>
>>These drivers (a
Hi,
it seems that PCI quirks are not handled on resume which results
in all kinds of strange effects, like disappeared PCI devices.
Below is a diff between "lspci -vvvxxx" before and after resume
for my SMBus device which only gets enabled by PCI quirk handling.
-:00:1f.3 SMBus: Intel Corp.
Hello Dave,
after suspend-to-ram and a subsequent resume the configuration
of my AGP bridge/controller is different and X will refuse to
start after resume if it wasn't running during suspend. I'm
using radeonfb as console driver and kernel 2.6.13-rc6-git6.
Diff between lspci -vvvxxx before and
Hello Dave,
after suspend-to-ram and a subsequent resume the configuration
of my AGP bridge/controller is different and X will refuse to
start after resume if it wasn't running during suspend. I'm
using radeonfb as console driver and kernel 2.6.13-rc6-git6.
Diff between lspci -vvvxxx before and
Hi,
it seems that PCI quirks are not handled on resume which results
in all kinds of strange effects, like disappeared PCI devices.
Below is a diff between lspci -vvvxxx before and after resume
for my SMBus device which only gets enabled by PCI quirk handling.
-:00:1f.3 SMBus: Intel Corp.
Alan Stern schrieb:
On Tue, 16 Aug 2005, Carl-Daniel Hailfinger wrote:
Hi,
[...]
Besides that, a number of drivers do not restore the pci config
space of their associated devices properly on resume from S3.
These drivers (and associated devices) are:
- uhci_hcd (USB Controller: Intel Corp
Rafael J. Wysocki schrieb:
> The following patch adds basic suspend/resume support to the sk98lin
> network driver.
[snipped]
The current in-kernel sk98lin driver is years behind the version
downloadable from Syskonnect. Maybe it would make sense to update
it first before applying any new
Rafael J. Wysocki schrieb:
The following patch adds basic suspend/resume support to the sk98lin
network driver.
[snipped]
The current in-kernel sk98lin driver is years behind the version
downloadable from Syskonnect. Maybe it would make sense to update
it first before applying any new patches.
Bas Vermeulen schrieb:
> On Fri, 2005-07-15 at 11:31 +0200, Carl-Daniel Hailfinger wrote:
>
>>Hi Jeff,
>>
>>I have a Intel ICH6M chipset and am using ata_piix as my
>>default disk driver. With the SUSE patched 2.6.11.4 kernel
>>(it has some libata patches) m
Hi Jeff,
I have a Intel ICH6M chipset and am using ata_piix as my
default disk driver. With the SUSE patched 2.6.11.4 kernel
(it has some libata patches) my DVD-RAM drive works, with
2.6.13-rc3 it doesn't work. My .config is nearly identical
for both kernels (except options introduced after
Hi Jeff,
I have a Intel ICH6M chipset and am using ata_piix as my
default disk driver. With the SUSE patched 2.6.11.4 kernel
(it has some libata patches) my DVD-RAM drive works, with
2.6.13-rc3 it doesn't work. My .config is nearly identical
for both kernels (except options introduced after
Russell King schrieb:
> On Tue, Mar 01, 2005 at 01:45:47AM +0100, Carl-Daniel Hailfinger wrote:
>
>>Can I prevent mtime updates for all device files? Mounting /dev readonly
>>would certainly help, but for that to work I'd have to move /dev to a
>>different filesystem,
Russell King schrieb:
On Tue, Mar 01, 2005 at 01:45:47AM +0100, Carl-Daniel Hailfinger wrote:
Can I prevent mtime updates for all device files? Mounting /dev readonly
would certainly help, but for that to work I'd have to move /dev to a
different filesystem, right?
tty mtime updates aren't
Arjan van de Ven schrieb:
> On Mon, 2005-02-28 at 00:51 +0100, Carl-Daniel Hailfinger wrote:
>
>>Hi,
>>
>>is it intentional that
>>echo foo >/dev/hda1
>>doesn't update the mtime of the device node, but
>>echo foo >/dev/tty10
>>does upda
Arjan van de Ven schrieb:
On Mon, 2005-02-28 at 00:51 +0100, Carl-Daniel Hailfinger wrote:
Hi,
is it intentional that
echo foo /dev/hda1
doesn't update the mtime of the device node, but
echo foo /dev/tty10
does update the mtime of the device node?
And no, mounting with the noatime flag
Hi,
is it intentional that
echo foo >/dev/hda1
doesn't update the mtime of the device node, but
echo foo >/dev/tty10
does update the mtime of the device node?
And no, mounting with the noatime flag doesn't help because the
mtime is updated. IIRC some time ago this behaviour was different,
but I
Hi,
is it intentional that
echo foo /dev/hda1
doesn't update the mtime of the device node, but
echo foo /dev/tty10
does update the mtime of the device node?
And no, mounting with the noatime flag doesn't help because the
mtime is updated. IIRC some time ago this behaviour was different,
but I
Pavel Machek schrieb:
>
>>>I'm not sure if you can push the whole industry at once.
>>
>>The goal is to know what to tell the system vendors
>>interested in supporting Linux what they should do
>>with their BIOS on future platforms.
>>
>>I believe our message should be:
>>1. BIOS should
Pavel Machek schrieb:
>
>>>to reinitialise the graphics hardware, few are going to care about
>>>making life easier for Linux.
>>
> [...]
>>3. Get some shiny certification/label going that can be put on
>>fully conforming products as a sticker. Something like the old
>>"EPA pollution preventer"
Vernon Mauery schrieb:
> Carl-Daniel Hailfinger wrote:
>
>>1. A first step towards better DSDTs would be to make the ASL compiler
>>complain about the same things which are complained about by the
>>in-kernel ACPI interpreter. An example would be the following:
>
Matthew Garrett schrieb:
> On Thu, 2005-02-17 at 01:16 -0500, Len Brown wrote:
>
>>I think that it is the BIOS' job on S3-suspend
>>to save the video mode. On S3-resume the BIOS should
>>re-POST and restore the video mode.
>
> I agree, but in the absence of spec requirement and some form of
>
Matthew Garrett schrieb:
On Thu, 2005-02-17 at 01:16 -0500, Len Brown wrote:
I think that it is the BIOS' job on S3-suspend
to save the video mode. On S3-resume the BIOS should
re-POST and restore the video mode.
I agree, but in the absence of spec requirement and some form of
Vernon Mauery schrieb:
Carl-Daniel Hailfinger wrote:
1. A first step towards better DSDTs would be to make the ASL compiler
complain about the same things which are complained about by the
in-kernel ACPI interpreter. An example would be the following:
acpi_processor-0496 [10
Pavel Machek schrieb:
to reinitialise the graphics hardware, few are going to care about
making life easier for Linux.
[...]
3. Get some shiny certification/label going that can be put on
fully conforming products as a sticker. Something like the old
EPA pollution preventer logo, but with a
Pavel Machek schrieb:
I'm not sure if you can push the whole industry at once.
The goal is to know what to tell the system vendors
interested in supporting Linux what they should do
with their BIOS on future platforms.
I believe our message should be:
1. BIOS should save/restore video in S3
Hi,
this patch is needed to make the SMBus device on my Samsung P35
laptop visible. By default, it doesn't appear as a pci device.
Patch tested, works perfectly for me. Please apply.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
Signed-off-by: Carl-Daniel Hailfinger <[EMAIL PROTEC
Stefan Dösinger schrieb:
>>The problems with this patch are:
>>- you need to press a key to come back from the "resume-console" after
>>resume. - DRI in X does not work (at least for me with intel-agp, others
>>reportet it works)
>>I just disabloed it by not loading intel-agp (hotplug-blacklist)
>
Romano Giannetti schrieb:
> On Tue, Feb 15, 2005 at 06:08:37PM +0100, Norbert Preining wrote:
>
>>On Die, 15 Feb 2005, Carl-Daniel Hailfinger wrote:
>>
>>>To suspend and resume properly, call the following script as root:
>>
>>Success.
>
> I tried wi
Romano Giannetti schrieb:
On Tue, Feb 15, 2005 at 06:08:37PM +0100, Norbert Preining wrote:
On Die, 15 Feb 2005, Carl-Daniel Hailfinger wrote:
To suspend and resume properly, call the following script as root:
Success.
I tried with my Sony Vaio FX701. No luck. It goes S3 ok
Stefan Dösinger schrieb:
The problems with this patch are:
- you need to press a key to come back from the resume-console after
resume. - DRI in X does not work (at least for me with intel-agp, others
reportet it works)
I just disabloed it by not loading intel-agp (hotplug-blacklist)
You can
Hi,
this patch is needed to make the SMBus device on my Samsung P35
laptop visible. By default, it doesn't appear as a pci device.
Patch tested, works perfectly for me. Please apply.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED
Matthew Garrett schrieb:
> On Tue, 2005-02-15 at 19:57 +0100, Carl-Daniel Hailfinger wrote:
>
>
>>Kendall Bennett is working with me to get suspend/resume working
>>even with framebuffers. Once we have results, I'll post them here.
>
>
> I've had success u
Norbert Preining schrieb:
> On Die, 15 Feb 2005, Carl-Daniel Hailfinger wrote:
>
>>To suspend and resume properly, call the following script as root:
>
>
> Success.
Great!
> After deactivating DRI in the X config file and saving the states with
> your script (than
Norbert Preining schrieb:
> On Mon, 14 Feb 2005, Pavel Machek wrote:
>
>>(1) systems where video state is preserved over S3.
>>
>>(2) systems where it is possible to call video bios during S3
>> resume. Unfortunately, it is not correct to call video BIOS at that
>> point, but it happens to work
Norbert Preining schrieb:
On Mon, 14 Feb 2005, Pavel Machek wrote:
(1) systems where video state is preserved over S3.
(2) systems where it is possible to call video bios during S3
resume. Unfortunately, it is not correct to call video BIOS at that
point, but it happens to work on some
Norbert Preining schrieb:
On Die, 15 Feb 2005, Carl-Daniel Hailfinger wrote:
To suspend and resume properly, call the following script as root:
Success.
Great!
After deactivating DRI in the X config file and saving the states with
your script (thanks) and turning off various stuff I
Matthew Garrett schrieb:
On Tue, 2005-02-15 at 19:57 +0100, Carl-Daniel Hailfinger wrote:
Kendall Bennett is working with me to get suspend/resume working
even with framebuffers. Once we have results, I'll post them here.
I've had success using vesafb with vbetool state restoration
Pavel Machek schrieb:
> Hi!
>
> Stefan provided me initial list of machines where S3 works (including
> video). If you have machine that is not on the list, please send me a
> diff. If you have eMachines... I'd like you to try playing with
> vbetool (it worked for me), and if it works for you
Pavel Machek schrieb:
Hi!
Stefan provided me initial list of machines where S3 works (including
video). If you have machine that is not on the list, please send me a
diff. If you have eMachines... I'd like you to try playing with
vbetool (it worked for me), and if it works for you supplying
Matt Domsch schrieb:
> On Thu, Feb 10, 2005 at 03:11:52PM +0100, Carl-Daniel Hailfinger wrote:
>
>>Hi Matt,
>>
>>it seems the edd=off patch has caused some problems with
>>some machines I have access to. They simply don't boot
>>anymore unless I specify edd
Li-Ta Lo schrieb:
> On Mon, 2005-02-07 at 09:01, Pavel Machek wrote:
>
3 - it's always there and can be executed at *any* time: booting,
returning from suspend, etc. Also it would allow the VESA framebuffer
driver to change graphics mode at any time (for instance).
>>>
>>>OK, and what
Jon Smirl schrieb:
> On Thu, 10 Feb 2005 21:06:36 +, Matthew Garrett <[EMAIL PROTECTED]> wrote:
>
>>On Thu, 2005-02-10 at 12:46 -0800, Kendall Bennett wrote:
>>
>>
>>>So perhaps this problem is something similar?
>
>
> What type of computer has the problem? Who makes it's video chips?
Hi Matt,
it seems the edd=off patch has caused some problems with
some machines I have access to. They simply don't boot
anymore unless I specify edd=foo. foo can be {off,skip,bar}
so it seems the hang on boot is related to the parser
not finding the parameter it is looking for.
I looked through
Hi Matt,
it seems the edd=off patch has caused some problems with
some machines I have access to. They simply don't boot
anymore unless I specify edd=foo. foo can be {off,skip,bar}
so it seems the hang on boot is related to the parser
not finding the parameter it is looking for.
I looked through
Jon Smirl schrieb:
On Thu, 10 Feb 2005 21:06:36 +, Matthew Garrett [EMAIL PROTECTED] wrote:
On Thu, 2005-02-10 at 12:46 -0800, Kendall Bennett wrote:
So perhaps this problem is something similar?
What type of computer has the problem? Who makes it's video chips?
Samsung P35 notebook
Li-Ta Lo schrieb:
On Mon, 2005-02-07 at 09:01, Pavel Machek wrote:
3 - it's always there and can be executed at *any* time: booting,
returning from suspend, etc. Also it would allow the VESA framebuffer
driver to change graphics mode at any time (for instance).
OK, and what would force you to
Matt Domsch schrieb:
On Thu, Feb 10, 2005 at 03:11:52PM +0100, Carl-Daniel Hailfinger wrote:
Hi Matt,
it seems the edd=off patch has caused some problems with
some machines I have access to. They simply don't boot
anymore unless I specify edd=foo. foo can be {off,skip,bar}
so it seems the hang
Paulo Marques schrieb:
> Adam Sulmicki wrote:
>
>>
>> hi all,
>> I would like point to work done by Li-Ta Lo.
>>
>> It allows you to completely initalize the VGA BIOS w/out using
>> PC BIOS at all.
>>
>>
>> http://www.clustermatic.org/pipermail/linuxbios/2005-January/010236.html
Paulo Marques schrieb:
Adam Sulmicki wrote:
hi all,
I would like point to work done by Li-Ta Lo.
It allows you to completely initalize the VGA BIOS w/out using
PC BIOS at all.
http://www.clustermatic.org/pipermail/linuxbios/2005-January/010236.html
unforunatelly
Xavier Bestel schrieb:
> Le vendredi 04 fÃvrier 2005 Ã 00:03 -0500, Jon Smirl a Ãcrit :
>
>>Doing this in user space lets you have two reset
>>programs, vm86 and emu86 for non-x86 machines.
>
>
> Perhaps only emu86 should be used, to have a well-debugged codepath on
> all archs (amd64, ppc,
James Simmons schrieb:
>>>int video_helper(struct video_actions *what_to_do)
>>
>>I do not know, synchronously executing userland code from kernel seems
>>like wrong thing to do.
>
> I'm not a fan for this either. The good news is most graphics cards don't
> require these tricks. The only ones
Pavel Machek schrieb:
>
> I do not understand how initramfs fits into picture... Plus lot of
> people (me :-) do not use initramfs...
Well, an initrd which is never unmounted should work, too. On SUSE,
"mkdir /initrd" and see what you've been missing. I don't know why
that directory doesn't
Jon Smirl schrieb:
> On Fri, 4 Feb 2005 08:44:54 +0100, Pavel Machek <[EMAIL PROTECTED]> wrote:
>
>>We already try to do that, but it hangs on 70% of machines. See
>>Documentation/power/video.txt.
>
> We know that all of these ROMs are run at power on so they have to
> work. This implies that
Jon Smirl schrieb:
> Reseting a video card from suspend is essentially the same problem as
> reseting secondary video cards on boot. The same code can address both
> problems.
>
> Some things to consider
>
> 1) With multiple video cards you have to ensure only a single VGA gets
> enabled.
Oliver Neukum schrieb:
> Am Freitag, 4. Februar 2005 08:48 schrieb Pavel Machek:
>
>>What about simply blocking all video accesses before disk (etc) is
>>resumed, so that "normal" (not locked in memory) application can be
>>used?
>
> Very bad for debugging. Genuine serial ports are becoming
Jon Smirl schrieb:
On Fri, 4 Feb 2005 08:44:54 +0100, Pavel Machek [EMAIL PROTECTED] wrote:
We already try to do that, but it hangs on 70% of machines. See
Documentation/power/video.txt.
We know that all of these ROMs are run at power on so they have to
work. This implies that there must be
Pavel Machek schrieb:
I do not understand how initramfs fits into picture... Plus lot of
people (me :-) do not use initramfs...
Well, an initrd which is never unmounted should work, too. On SUSE,
mkdir /initrd and see what you've been missing. I don't know why
that directory doesn't exist by
James Simmons schrieb:
int video_helper(struct video_actions *what_to_do)
I do not know, synchronously executing userland code from kernel seems
like wrong thing to do.
I'm not a fan for this either. The good news is most graphics cards don't
require these tricks. The only ones that do are
Xavier Bestel schrieb:
Le vendredi 04 fvrier 2005 00:03 -0500, Jon Smirl a crit :
Doing this in user space lets you have two reset
programs, vm86 and emu86 for non-x86 machines.
Perhaps only emu86 should be used, to have a well-debugged codepath on
all archs (amd64, ppc, ...)
As it's
Oliver Neukum schrieb:
Am Freitag, 4. Februar 2005 08:48 schrieb Pavel Machek:
What about simply blocking all video accesses before disk (etc) is
resumed, so that normal (not locked in memory) application can be
used?
Very bad for debugging. Genuine serial ports are becoming rarer.
As a
Jon Smirl schrieb:
Reseting a video card from suspend is essentially the same problem as
reseting secondary video cards on boot. The same code can address both
problems.
Some things to consider
1) With multiple video cards you have to ensure only a single VGA gets
enabled. Running
Hi!
Nigel Cunningham wrote:
> Hi.
>
> On Fri, 2005-02-04 at 09:54, Pavel Machek wrote:
>
>>Hi!
>>
>>
>Are you able to use framebuffer(radeonfb,1024x768) with this
>configuration or do you need to use plain vga-console for it to work?
No.
For a working framebuffer console
Hi!
Nigel Cunningham wrote:
Hi.
On Fri, 2005-02-04 at 09:54, Pavel Machek wrote:
Hi!
Are you able to use framebuffer(radeonfb,1024x768) with this
configuration or do you need to use plain vga-console for it to work?
No.
For a working framebuffer console you would have to perform the
77 matches
Mail list logo
