* Question on States monitoring @ 2018-05-14 15:46 Andres Oportus 2018-05-14 23:16 ` Andrew Jeffery 0 siblings, 1 reply; 8+ messages in thread From: Andres Oportus @ 2018-05-14 15:46 UTC (permalink / raw) To: openbmc Are there any ongoing efforts on expanding States (say provided by GPIOs) monitoring/management? I see that phosphor-state-manager has Chassis/Host/BMC states that are placed onto DBUS but not a more generic mechanism. On the GPIO specific side, I see that phosphor-gpio-monitor allows for interrupt driven GPIO monitoring (seemly only used under a gpio-keys driver with /dev/input for Power's checkstop monitoring?), but no generic GPIO setting/getting for those not allowing interrupt type monitoring (say output GPIOs). Thanks, Andres ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Question on States monitoring 2018-05-14 15:46 Question on States monitoring Andres Oportus @ 2018-05-14 23:16 ` Andrew Jeffery 2018-05-14 23:26 ` Andres Oportus 0 siblings, 1 reply; 8+ messages in thread From: Andrew Jeffery @ 2018-05-14 23:16 UTC (permalink / raw) To: Andres Oportus, openbmc Hi Andres, On Tue, 15 May 2018, at 01:16, Andres Oportus wrote: > Are there any ongoing efforts on expanding States (say provided by GPIOs) > monitoring/management? I see that phosphor-state-manager has > Chassis/Host/BMC states that are placed onto DBUS but not a more generic > mechanism. On the GPIO specific side, I see that phosphor-gpio-monitor > allows for interrupt driven GPIO monitoring (seemly only used under a > gpio-keys driver with /dev/input for Power's checkstop monitoring?), but no > generic GPIO setting/getting for those not allowing interrupt type > monitoring (say output GPIOs). It's not clear to me what you're looking for here. Are you hoping for something to expose the GPIOs on DBus? I don't think we have anything like that, which is more of a design philosophy thing (we should probably provide a higher-level capability on DBus, not just directly expose GPIOs). Alternatively if you're looking to handle GPIOs from your application, I would recommend libgpiod: https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/ Cheers, Andrew ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Question on States monitoring 2018-05-14 23:16 ` Andrew Jeffery @ 2018-05-14 23:26 ` Andres Oportus 2018-05-15 1:49 ` Lei YU 0 siblings, 1 reply; 8+ messages in thread From: Andres Oportus @ 2018-05-14 23:26 UTC (permalink / raw) To: andrew; +Cc: openbmc [-- Attachment #1: Type: text/plain, Size: 1746 bytes --] Thanks Andrew, yeah I see the design philosophy of not exposing low level stuff like GPIOs unless they mean something more high level (hence the "State" reference) that could be exposed/monitored/changed/etc. I'm just checking to see if we have anything already being thought of or implemented as to not come up with a custom solution. The problem is managing "States" at least initially backed by GPIOs, and it does not have to be on the DBUS although from what I've seen for instance on IPMI we use DBUS extensively for things that get exported. On Mon, May 14, 2018 at 4:16 PM Andrew Jeffery <andrew@aj.id.au> wrote: > Hi Andres, > > On Tue, 15 May 2018, at 01:16, Andres Oportus wrote: > > Are there any ongoing efforts on expanding States (say provided by GPIOs) > > monitoring/management? I see that phosphor-state-manager has > > Chassis/Host/BMC states that are placed onto DBUS but not a more generic > > mechanism. On the GPIO specific side, I see that phosphor-gpio-monitor > > allows for interrupt driven GPIO monitoring (seemly only used under a > > gpio-keys driver with /dev/input for Power's checkstop monitoring?), but > no > > generic GPIO setting/getting for those not allowing interrupt type > > monitoring (say output GPIOs). > > It's not clear to me what you're looking for here. Are you hoping for > something to expose the GPIOs on DBus? I don't think we have anything like > that, which is more of a design philosophy thing (we should probably > provide a higher-level capability on DBus, not just directly expose GPIOs). > > Alternatively if you're looking to handle GPIOs from your application, I > would recommend libgpiod: > > https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/ > > Cheers, > > Andrew > [-- Attachment #2: Type: text/html, Size: 2705 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Question on States monitoring 2018-05-14 23:26 ` Andres Oportus @ 2018-05-15 1:49 ` Lei YU 2018-05-15 1:53 ` Andrew Jeffery 0 siblings, 1 reply; 8+ messages in thread From: Lei YU @ 2018-05-15 1:49 UTC (permalink / raw) To: Andres Oportus; +Cc: Andrew Jeffery, OpenBMC Maillist Hi Andres, The existing [phosphor-gpio-monitor][1] contains two services, one is for monitor gpio interrupts, the other is "phosphor-gpio-presence" that checks a gpio output and let it be some state on DBus. I guess the "presence" service is what you are looking for, that maps a gpio output to a Dbus object. The existing use case is: 1. Witherspoon checks if power supply is connected and create dbus object /inventory/system/chassis/motherboard/powersupplyX, it also is able to bind the kernel driver when it is attached. 2. Zaius checks if a PCIE card is connected on E2B and create dbus object /inventory/system/chassis/pcie_card_e2b You can see a little detailed explanation at https://github.com/mine260309/openbmc-intro/blob/master/Porting_Guide.md#gpio-presence [1]: https://github.com/openbmc/phosphor-gpio-monitor On Tue, May 15, 2018 at 7:26 AM, Andres Oportus <andresoportus@google.com> wrote: > Thanks Andrew, yeah I see the design philosophy of not exposing low level > stuff like GPIOs unless they mean something more high level (hence the > "State" reference) that could be exposed/monitored/changed/etc. I'm just > checking to see if we have anything already being thought of or implemented > as to not come up with a custom solution. The problem is managing "States" > at least initially backed by GPIOs, and it does not have to be on the DBUS > although from what I've seen for instance on IPMI we use DBUS extensively > for things that get exported. > > On Mon, May 14, 2018 at 4:16 PM Andrew Jeffery <andrew@aj.id.au> wrote: >> >> Hi Andres, >> >> On Tue, 15 May 2018, at 01:16, Andres Oportus wrote: >> > Are there any ongoing efforts on expanding States (say provided by >> > GPIOs) >> > monitoring/management? I see that phosphor-state-manager has >> > Chassis/Host/BMC states that are placed onto DBUS but not a more generic >> > mechanism. On the GPIO specific side, I see that phosphor-gpio-monitor >> > allows for interrupt driven GPIO monitoring (seemly only used under a >> > gpio-keys driver with /dev/input for Power's checkstop monitoring?), but >> > no >> > generic GPIO setting/getting for those not allowing interrupt type >> > monitoring (say output GPIOs). >> >> It's not clear to me what you're looking for here. Are you hoping for >> something to expose the GPIOs on DBus? I don't think we have anything like >> that, which is more of a design philosophy thing (we should probably provide >> a higher-level capability on DBus, not just directly expose GPIOs). >> >> Alternatively if you're looking to handle GPIOs from your application, I >> would recommend libgpiod: >> >> https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/ >> >> Cheers, >> >> Andrew ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Question on States monitoring 2018-05-15 1:49 ` Lei YU @ 2018-05-15 1:53 ` Andrew Jeffery 2018-05-15 1:57 ` Lei YU 0 siblings, 1 reply; 8+ messages in thread From: Andrew Jeffery @ 2018-05-15 1:53 UTC (permalink / raw) To: Lei YU, Andres Oportus; +Cc: OpenBMC Maillist Hi Lei, On Tue, 15 May 2018, at 11:19, Lei YU wrote: > Hi Andres, > > The existing [phosphor-gpio-monitor][1] contains two services, one is for > monitor gpio interrupts, the other is "phosphor-gpio-presence" that checks a > gpio output and let it be some state on DBus. > > I guess the "presence" service is what you are looking for, that maps a > gpio output to a Dbus object. > > The existing use case is: > 1. Witherspoon checks if power supply is connected and create dbus object > /inventory/system/chassis/motherboard/powersupplyX, it also is able to > bind the kernel driver when it is attached. > 2. Zaius checks if a PCIE card is connected on E2B and create dbus object > /inventory/system/chassis/pcie_card_e2b > > You can see a little detailed explanation at > https://github.com/mine260309/openbmc-intro/blob/master/Porting_Guide.md#gpio-presence That porting guide looks like it has some interesting info, and I feel like we should probably make it part of the docs repository. Did you have any plans on integrating it? Cheers, Andrew ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Question on States monitoring 2018-05-15 1:53 ` Andrew Jeffery @ 2018-05-15 1:57 ` Lei YU 2018-05-15 5:05 ` Andres Oportus 0 siblings, 1 reply; 8+ messages in thread From: Lei YU @ 2018-05-15 1:57 UTC (permalink / raw) To: Andrew Jeffery; +Cc: Andres Oportus, OpenBMC Maillist On Tue, May 15, 2018 at 9:53 AM, Andrew Jeffery <andrew@aj.id.au> wrote: > Hi Lei, > > On Tue, 15 May 2018, at 11:19, Lei YU wrote: >> Hi Andres, >> >> The existing [phosphor-gpio-monitor][1] contains two services, one is for >> monitor gpio interrupts, the other is "phosphor-gpio-presence" that checks a >> gpio output and let it be some state on DBus. >> >> I guess the "presence" service is what you are looking for, that maps a >> gpio output to a Dbus object. >> >> The existing use case is: >> 1. Witherspoon checks if power supply is connected and create dbus object >> /inventory/system/chassis/motherboard/powersupplyX, it also is able to >> bind the kernel driver when it is attached. >> 2. Zaius checks if a PCIE card is connected on E2B and create dbus object >> /inventory/system/chassis/pcie_card_e2b >> >> You can see a little detailed explanation at >> https://github.com/mine260309/openbmc-intro/blob/master/Porting_Guide.md#gpio-presence > > That porting guide looks like it has some interesting info, and I feel like we should probably make it part of the docs repository. Did you have any plans on integrating it? Yup, I will submit to openbmc/doc (when it's somehow ready). This doc is my attempt to help system vendors to know OpenBMC and get it ported on their machine. And for now I have sent this to 2 or 3 vendors and ask for feedback. It's not completed yet as I need to add one more page for some development tips, e.g. how to quickly modify a code and get it tested. > > Cheers, > > Andrew ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Question on States monitoring 2018-05-15 1:57 ` Lei YU @ 2018-05-15 5:05 ` Andres Oportus 2018-05-15 12:32 ` Lei YU 0 siblings, 1 reply; 8+ messages in thread From: Andres Oportus @ 2018-05-15 5:05 UTC (permalink / raw) To: mine260309; +Cc: andrew, openbmc On Mon, May 14, 2018 at 6:57 PM Lei YU <mine260309@gmail.com> wrote: > On Tue, May 15, 2018 at 9:53 AM, Andrew Jeffery <andrew@aj.id.au> wrote: > > Hi Lei, > > > > On Tue, 15 May 2018, at 11:19, Lei YU wrote: > >> Hi Andres, > >> > >> The existing [phosphor-gpio-monitor][1] contains two services, one is for > >> monitor gpio interrupts, the other is "phosphor-gpio-presence" that checks a > >> gpio output and let it be some state on DBus. > >> > >> I guess the "presence" service is what you are looking for, that maps a > >> gpio output to a Dbus object. > >> > >> The existing use case is: > >> 1. Witherspoon checks if power supply is connected and create dbus object > >> /inventory/system/chassis/motherboard/powersupplyX, it also is able to > >> bind the kernel driver when it is attached. > >> 2. Zaius checks if a PCIE card is connected on E2B and create dbus object > >> /inventory/system/chassis/pcie_card_e2b > >> > >> You can see a little detailed explanation at > >> https://github.com/mine260309/openbmc-intro/blob/master/Porting_Guide.md#gpio-presence > > Thanks for info. It seems that since both monitor and presence are subclasses from Evdev they, at least in their current form, need GPIOs to be setup as input (in the examples use /dev/input devices) with a driver like gpio-keys, is this the case? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Question on States monitoring 2018-05-15 5:05 ` Andres Oportus @ 2018-05-15 12:32 ` Lei YU 0 siblings, 0 replies; 8+ messages in thread From: Lei YU @ 2018-05-15 12:32 UTC (permalink / raw) To: Andres Oportus; +Cc: Andrew Jeffery, OpenBMC Maillist > Thanks for info. It seems that since both monitor and presence are > subclasses from Evdev they, at least in their current form, need GPIOs to > be setup as input (in the examples use /dev/input devices) with a driver > like gpio-keys, is this the case? Yup, at this level they are the same, using the same driver. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2018-05-15 12:32 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-05-14 15:46 Question on States monitoring Andres Oportus 2018-05-14 23:16 ` Andrew Jeffery 2018-05-14 23:26 ` Andres Oportus 2018-05-15 1:49 ` Lei YU 2018-05-15 1:53 ` Andrew Jeffery 2018-05-15 1:57 ` Lei YU 2018-05-15 5:05 ` Andres Oportus 2018-05-15 12:32 ` Lei YU
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.