10

Ich versuche, einen Spannungsregler zu steuern (an/aus), der einem GPIO-Pin zugeordnet ist und ein externes Gerät antreibt. Der Gerätebaum für den Regler hat folgenden Eintrag:Interpretation von gpio: in fest-Regler-Gerät Baum Eintrag?

reg_usb1_vbus: usb1_vbus { 
     compatible = "regulator-fixed"; 
     regulator-name = "usb1_vbus"; 
     regulator-min-microvolt = <5000000>; 
     regulator-max-microvolt = <5000000>; 
     gpio = <&gpio3 28 0>; 
     enable-active-high; 
    }; 

Als ich the documentation las ich für sie verwirrt habe es heißt:

Optional Eigenschaften:

  • gpio: gpio zu verwenden zur Aktivierung der Steuerung

Allerdings kann ich die sysfs-Schnittstelle dieses GPIO nicht exportieren und damit die Stromversorgung (nur ein/aus) für das externe Gerät steuern. Zusätzlich, wenn ich die gpio = <&gpio3 28 0>; aus der Gerätestruktur auskommentiere, erhält das externe Gerät keinen Strom (wenn es nicht kommentiert ist, wird das Gerät immer mit Strom versorgt).

Der Regler verfügt über eine sysfs Schnittstelle exportiert:

80090000.usb-vbus  power     suspend_standby_state 
device     state     type 
microvolts    subsystem    uevent 
name     suspend_disk_state 
num_users    suspend_mem_state 

aber ich kann nicht auf eine der Dateien schreiben.

Was ist die korrekte Art, den gpio: Eintrag zu interpretieren?

  • GPIO zur Steuerung ermöglichen verwenden

    In diesem Fall bin ich eine Zuordnung zwischen einem Stift fehlt, an dem ich die Reglerspannung haben wollen.

  • gpio, die die Spannung vom Regler haben eine externe Einheit

    In diesem Fall fehlt mir einen Weg an die Macht es auf ein- und auszuschalten

+1

Der gpio DT Eintrag würde vermutlich für eine Freigabe via HW sein. Sobald der Treiber den angegebenen GPIO für seine Verwendung erhält, ist er nicht mehr unbenutzt und Sie können diesen GPIO nicht mehr über sysfs exportieren. Anscheinend suchen Sie nach einer SW- oder CLI-Aktivierung? Suchen Sie in sysfs nach einer vorhandenen Instanz dieses GPIO, die Sie nicht exportieren müssen. Suchen Sie nach einer SW-gesteuerten Freigabe, indem Sie im Treiber einen Aufruf ** ioctl() ** verwenden. Im schlimmsten Fall wäre es, ein anderes GPIO mit dieser HW-Freigabe zu verbinden. – sawdust

+0

@sawdust 'Sobald der Treiber den spezifizierten GPIO für seine Verwendung erwirbt, versuche ich zu verstehen, was die Richtlinie dafür ist. Die Gerätebaumdokumentationen geben an, dass gpio: gpio für die Aktivierungssteuerung verwendet werden soll, aber ich empfinde es als die Anweisung, den Regler mit einem GPIO-Pin zuzuordnen. – TheMeaningfulEngineer

+0

Es ist eine Frage der Ressourcenverteilung. Genau wie Speicher zugewiesen und freigegeben wird, sind auch GPIO-Pins. Überprüfen Sie den Treiber für diesen Regler. Es ruft wahrscheinlich den DT-Eintrag für seinen GPIO mit einem Aufruf von ** of_get_gpio() ** oder ** of_property_read_u32() ** ab. Der Wert wird normalerweise mit ** gpio_is_valid() ** getestet und dann mit ** gpio_request() ** zugewiesen. Wenn Sie einen GPIO mit sysfs exportieren, muss sysfs (versuchen Sie es), den Pin zu erhalten. Was ist in sysfs für diesen Regler, z.B. unter **/sys/klasse/regler **? – sawdust

Antwort

6

Ich versuche einen Spannungsregler zu steuern (an/aus), der einem GPIO-Pin zugeordnet ist und ein externes Gerät antreibt.
...

Wie ist der richtige Weg, den Eintrag gpio zu interpretieren?

Scheint so, als ob Sie eine XY-Frage stellen.
Zuerst der Y-Teil bezüglich des GPIO.

Der DT-Eintrag gpio, auf den Sie sich beziehen, würde für eine Aktivierung/Deaktivierung durch das Regler-Framework dienen. Es ist ausschließlich zur Verwendung durch den Reglertreiber vorgesehen, um die (externe?) Reglerhardware zu steuern. Es ist nicht für die Software-Steuerung des Reglers außerhalb des Rahmens durch den Benutzer gedacht (wie Sie es versuchen).

Diese GPIO wird als Ausgabe in Treiber/Regler/core.c definiert:

static int regulator_ena_gpio_request(struct regulator_dev *rdev, 
           const struct regulator_config *config) 
{ 
     ... 
     ret = gpio_request_one(config->ena_gpio, 
           GPIOF_DIR_OUT | config->ena_gpio_flags, 
           rdev_get_name(rdev)); 
     ... 
} 

Der GPIO-Pin nicht für gelesen wird "enable control", hat aber in seinem Wert gesetzt reglers_ena_gpio_ctrl(), um den (externen) Regler aktiv zu aktivieren oder zu deaktivieren.

Die Möglichkeit, den gleichen GPIO-Pin mit sysfs zu exportieren, wenn dieser Pin auch im Device Tree deklariert ist, wird leicht erklärt. Sobald der Treiber den angegebenen GPIO für seine Verwendung (über das DT) erwirbt, wird er nicht mehr verwendet, und Sie können diesen GPIO nicht mehr über sysfs exportieren. GPIOs sind eine verwaltete Ressource und müssen (wie bei jeder anderen Ressource, z. B. Speicher) von einem Treiber oder sysfs zugewiesen und freigegeben werden. Wenn Sie diesen GPIO exportieren könnten, der auch vom Treiber verwendet wurde, könnten Sie den GPIO in einen Zustand versetzen, der nicht dem entspricht, was der Treiber getan hat. Dies wiederum würde zu einem instabilen oder sich schlecht benehmenden Code führen.

In diesem Fall fehlt mir eine Zuordnung zwischen einem Pin, auf dem ich die Reglerspannung haben möchte.

Der im Gerätebaum angegebene GPIO-Pin ist ein logischer (d. H. Digitaler) Ausgang. Es ist nicht der Reglerausgang, der ein analoger Ausgang wäre.

Sie sollten den Schaltplan für Ihre Platine konsultieren, um zu bestätigen, dass dieser GPIO mit einem Steuereingang eines Reglers verbunden ist.


In Bezug auf die X-Teil in Bezug auf die Aktivierung/Deaktivierung des Reglers:

Software die Kontrolle über den Ausgang des Reglers in Documentation/power/regulator/consumer.txt

Ein Verbraucher Fahrer dokumentiert ist, kann den Zugang zu seinem Versorgungsregler erhalten, indem Berufung: -

regulator = regulator_get(dev, "Vcc"); 

Ein Verbraucher kann durch den Aufruf der Stromversorgung ermöglichen: -

int regulator_enable(regulator); 

Ein Verbraucher kann seine Versorgung deaktivieren, wenn nicht mehr benötigt wird durch den Aufruf: -

int regulator_disable(regulator); 

Der "Verbraucher" ist ein elektronisches Gerät, das ich s versorgt durch einen Regler.

Offensichtlich ist der beabsichtigte Rahmen haben die "Consumer-Treiber" besitzen und steuern ihren Regler, und nicht zulassen, dass eine externe Schnittstelle (z. B. sysfs) mit diesem "Consumer-Treiber" stören. Wenn Sie darauf bestehen, Benutzerland-Kontrolle zu haben, dann könnten Sie eine ioctl() oder Sysfs-Schnittstelle zum "Consumer-Treiber" implementieren (um Konflikte/Konflikte mit dem Reglertreiber zu vermeiden).

In diesem Fall fehlt mir einen Weg, es zu aktivieren und deaktivieren

Was du wirklich für scheint der Suche zu sein (obere Schicht) Power-Management-, und das hat einen eigenen Rahmen, bei dem es sich bei den Regulierungsbehörden um eine untere Ebene handelt (die normalerweise nicht für die Benutzerkontrolle zugänglich ist). Sie sollten Documentation/power/devices.txt studieren.

0

Ich bin nicht sehr vertraut mit dem Reglerkern im Kernel, aber mir scheint, dass die Reglerschnittstelle Ihnen Zugriff auf den GPIO auf andere Weise geben muss als die Standard-GPIO-Methode.

Ich habe das nicht untersucht, aber es ist möglich, dass die Reglerschnittstelle ein Zeichengerät für den Benutzerraum zur Steuerung des Reglers öffnet. (Halten Sie mich nicht daran)

Ich sehe in der Dokumentation und im Treiberquellcode drivers/regulator/fixed.c, dass das GPIO kein erforderliches DT-Attribut ist. Sie können es möglicherweise aus dem DT herauslassen, in welchem ​​Fall der Treiber Ihr GPIO niemals abruft, dann können Sie es manuell über die Standard-GPIO-Exportschnittstelle steuern.

+0

* "Sie können es vielleicht aus dem DT lassen ... dann können Sie es manuell über die Standard-GPIO-Schnittstelle exportieren." * - Das ist unlogisch. Wenn dem Treiber keine GPIO-Nummer zugewiesen ist, woher weiß der Treiber dann, welche GPIO-Nummer verwendet werden soll? Ein gut geschriebener Treiber (für Portabilität) sollte keine fest codierte GPIO-Nummer haben. Sie vermissen die Verwendung eines Gerätebaums. – sawdust

+0

@sawdust Es gibt einen Grund, warum der Treiber dies optional zulässt. Es ist, weil es für den richtigen Betrieb des Reglers nicht notwendig ist. Es wäre nicht hart codiert, es würde einfach nicht verwendet werden. Von drivers/regulator/fixed.c "of_get_named_gpio() unterscheidet nicht zwischen einer fehlenden Eigenschaft (was hier in Ordnung wäre, da das GPIO optional ist) und einem anderen Fehler." Der GPIO wird für eine Freigabe verwendet, und obwohl ich zustimme, dass ein guter Treiber sich um alle Hardwareschnittstellen mit dem Regler kümmern sollte, erfordert dies nicht, dass dies der Fall ist. – whh4000

+0

Es ist auch möglich, dass für den bestimmten Regler, dass der Designer entschieden hat, dass es dauerhaft aktiviert ist, und somit würde die Hardware diesen Pin direkt in den richtigen Zustand gezogen haben. Dann würde es keinen Sinn machen, den Treiber zu zwingen, einen GPIO zu haben. – whh4000