linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
To: acooks@rationali.st, Jean Delvare <jdelvare@suse.de>,
	Linux I2C <linux-i2c@vger.kernel.org>
Cc: Wolfram Sang <wsa@the-dreams.de>,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	platypus-sw@opengear.com, "Tobin C . Harding" <me@tobin.cc>,
	Guenter Roeck <linux@roeck-us.net>,
	Will Wagner <willw@carallon.com>
Subject: Re: [PATCH v5 0/3] Enable ACPI-defined peripherals on i2c-piix4 SMBus
Date: Mon, 19 Aug 2019 20:30:30 +0200	[thread overview]
Message-ID: <9019cce9-837f-97fc-0f3b-7503b8fc3717@metux.net> (raw)
In-Reply-To: <db725a3b-7b6e-ac79-ef1c-e601ff45c0f2@rationali.st>

On 11.08.19 04:52, Andrew Cooks wrote:

Hi,

> My initial work is based on a board that is similar to the APU2, but has additional peripherals connected to the smbus, including a NCT7491 thermal monitor/fan controller and PCA6524 GPIO controller. These are simply peripherals on a board variant, not 'platform' devices, so I didn't want to follow the platform driver approach that the APU2 GPIO driver uses.

Why are they not platform devices ?

IMHO, a platform device is something not on a bus that can do the
probing/enumeration (like eg. pci or usb does).

Can these devices be probed directly by the bus they're connected to,
or do you have a different definition of the term "platform device" ?

:O

> SMBus (and I2C) peripherals can generally not be enumerated without some firmware support. It is possible to probe for specific devices on the bus (eg sensors-detect) but in general it is not feasible to let every supported device driver probe the bus for its device. ACPI and Devicetree provides the kernel with metadata for the device: type, address, calibrated set points for temperature, etc.

Yes, I know. My question was whether these particular devices - if
they're in the SoC itself - do need some extra support in BIOS
(acpi entries, etc), that's not already in aegesa. Or in other words:
do I need to patch my BIOS ?

I was assuming these devices are in the SoC itself - correct me if
I'm wrong.

> Since the peripherals are not standard platform devices, they are not described by the ACPI tables provided by Coreboot or AMD, but it's not too difficult to create supplementary device description tables (ACPI) for non-standard devices. These can be added to coreboot, supplied to qemu as additional firmware files (see -acpitable arg), or built into the kernel (see https://www.kernel.org/doc/Documentation/acpi/ssdt-overlays.txt)

Oh, I didn't know about SSDT overlays yet. That's interesting.

Is it also possible to describe things like leds-gpio or gpio-keyboard ?
Could be a nice idea to trim down my apu2 driver to not much more than
a piece of configuration (just like we'd do on a DT-based system)

> ACPI may be an ugly abomination, but it's what we're stuck with on x86 and it can only improve when more people get their hands on it.

hmm, I'm planning to introduce DT to x86 (also patch up apu'2 coreboot
do deliver a DT to the kernel) ... but just lacking time to get my hands
dirty on this topic.

> You might find it helpful to look at the coreboot source for the APU2 (src/mainboard/pcengines/apu2/gpio_ftns.h)

In which version ?


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

  reply	other threads:[~2019-08-19 18:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-02 12:51 [PATCH v5 0/3] Enable ACPI-defined peripherals on i2c-piix4 SMBus Jean Delvare
2019-08-02 12:52 ` [PATCH v5 1/3] i2c: piix4: Fix port selection for AMD Family 16h Model 30h Jean Delvare
2019-08-29 20:19   ` Wolfram Sang
2019-08-02 12:54 ` [PATCH v5 2/3] i2c: piix4: Fix probing of reserved ports on " Jean Delvare
2019-08-29 20:20   ` Wolfram Sang
2019-08-02 12:55 ` [PATCH v5 3/3] i2c: piix4: Add ACPI support Jean Delvare
2019-08-29 20:21   ` Wolfram Sang
2019-08-08  9:17 ` [PATCH v5 0/3] Enable ACPI-defined peripherals on i2c-piix4 SMBus Enrico Weigelt, metux IT consult
2019-08-09  8:33   ` Jean Delvare
2019-08-09 15:53     ` Enrico Weigelt, metux IT consult
2019-08-14 16:07       ` Wolfram Sang
2019-08-11  3:09     ` Andrew Cooks
2019-08-11  2:52   ` Andrew Cooks
2019-08-19 18:30     ` Enrico Weigelt, metux IT consult [this message]
2019-08-19 18:53       ` Wolfram Sang
2019-08-20 10:42         ` Enrico Weigelt, metux IT consult
2019-08-20 10:53           ` Wolfram Sang
2019-08-28 22:48       ` Andrew Cooks

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=9019cce9-837f-97fc-0f3b-7503b8fc3717@metux.net \
    --to=lkml@metux.net \
    --cc=acooks@rationali.st \
    --cc=jdelvare@suse.de \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=me@tobin.cc \
    --cc=platypus-sw@opengear.com \
    --cc=willw@carallon.com \
    --cc=wsa@the-dreams.de \
    /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).