linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Drake <dsd@laptop.org>
To: Samuel Ortiz <sameo@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, laforge@gnumonks.org
Subject: Re: [PATCH] Add VIA VX855 multi-function device support
Date: Wed, 29 Sep 2010 19:26:12 +0100	[thread overview]
Message-ID: <AANLkTinK8KScJ6Ux69w_ou4bbjsk8phb_2cokB-ZniFm@mail.gmail.com> (raw)
In-Reply-To: <AANLkTi=95qyBwvUamCqPsR_Yox5ybcK3k2NNNZjDqAKy@mail.gmail.com>

Sorry, hit send too early.

On 29 September 2010 19:21, Daniel Drake <dsd@laptop.org> wrote:
> Thanks. I've made the change locally but have run into a problem.
>
> mfd_add_devices calls acpi_check_resource_conflict() on each resource.
> And as noted in the earlier patch, ACPI also has a region reserved.
> Because acpi_check_resource_conflict() says there is a conflict,
> mfd_add_devices() bails out before registering the devices.
>
> So I've researched the conflict.
> The GPIO driver is trying to reserve region 0x420 - 0x452
> ACPI reports a conflict on "PRIE" 0x434
>
> Indeed, 0x434 is something ACPI-specific, so ACPI is right to say "get
> off my turf", and actually there are a whole host of non-GPIO things
> intermixed with GPIO things within the region 0x420 - 0x452.
>
> So, I thought about making the driver only reserve the 2 ports that it
> uses: 0x448,  0x44c
>
> However, ACPI has also reserved 0x448. This is because the XO-1.5 also
> uses GPIOs for the lid switch and ebook switch, which are basically
> presented to the OS as normal ACPI buttons. This particular byte
> includes a range of GPIOs including the ones that ACPI uses internally
> (the switches) plus the ones that we want to make available through
> the gpio driver.
>
> So, we're running into a limitation with Linux's model that

...an individual byte is either owned by one driver or another. In
this case, we want certain bits to belong to ACPI and other bits to
belong to the gpio driver. And given that these are "general purpose"
I/Os, this sharing even seems reasonable.

Any thoughts on what we can do?
Perhaps we could avoid using the mfd cell resource mechanism for the
GPIO ports, go back to passing them some other way, and attempting to
reserve the 2 needed ports but not bailing out if they can't be
reserved.

Thanks,
Daniel

  reply	other threads:[~2010-09-29 18:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-19 17:23 [PATCH] Add VIA VX855 multi-function device support Daniel Drake
2010-09-27 16:57 ` Samuel Ortiz
2010-09-29 18:21   ` Daniel Drake
2010-09-29 18:26     ` Daniel Drake [this message]
2010-09-26 15:05 Daniel Drake
2010-09-26 17:07 ` Harald Welte

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=AANLkTinK8KScJ6Ux69w_ou4bbjsk8phb_2cokB-ZniFm@mail.gmail.com \
    --to=dsd@laptop.org \
    --cc=laforge@gnumonks.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sameo@linux.intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).