All of lore.kernel.org
 help / color / mirror / Atom feed
From: j.w.r.degoede@hhs.nl (Hans de Goede)
To: lm-sensors@vger.kernel.org
Subject: [lm-sensors] Solution for ACPI <-> lmsensors arbitration?
Date: Wed, 14 Mar 2007 19:55:44 +0000	[thread overview]
Message-ID: <45F85340.2080702@hhs.nl> (raw)

Hi all,

In order to better understand the PC8374L datasheet I've also been reading the 
w83627hf datasheet, and I noticed that the w83627hf contains a driver 
arbitration mechanism in hardware. This may not be the case for all hwmon's but 
I believe that we should start supporting this for those who do. The address 
register of the hwmonitor part has a busy flag, currently the code for reading 
from it says:
/*
    ISA access must always be locked explicitly!
    We ignore the W83781D BUSY flag at this moment - it could lead to deadlocks,
    would slow down the W83781D access and should not be necessary.
    There are some ugly typecasts here, but the good news is - they should
    nowhere else be necessary! */

If we would check this first and an address was written by ACPI, then we would 
know to wait. The only problem is that there is a race between the time we 
check the bit and then write our own access, I'm currently thinking about 
fixing this as follows:

while (!access_successfull && attemps)
{
    if (busy)
        sleep
    else
    {
        disableinterrupts() /* or take a lock shared with acpi,
            but then we still have SMI problems, can we disable SMI too?
            or maybe only acpi-lock + mask SMI? */
        if (!busy)
        {
           do_read_or_write();
           access_successfull = 1;
        }
        enableinterrupts()
    }
    attemps--; /* do we need this? */
}

I know this isn't pretty, but it should work, right? Comments?

Regards,

Hans


             reply	other threads:[~2007-03-14 19:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-14 19:55 Hans de Goede [this message]
2007-03-15  7:22 ` [lm-sensors] Solution for ACPI <-> lmsensors arbitration? Jean Delvare

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45F85340.2080702@hhs.nl \
    --to=j.w.r.degoede@hhs.nl \
    --cc=lm-sensors@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.