phosphor-bittware repository

phosphor-bittware repository

[Ben_Pai]

[-- Attachment #1: Type: text/plain, Size: 1842 bytes --]

Hello Patrick


On Thu, May 07, 2020 at 06:07:44AM +0000, Ben_Pai at wistron.com<https://lists.ozlabs.org/listinfo/openbmc> wrote:

> Could you please help to create a new repository for phosphor-bittware?



Out of curiousity for others who aren't aware of what 'bittware' is,

could you describe a little about this repository?  It seems to be a

hardware vendor, so it would be interesting to know what the BMC will be

doing with it.



Examples:

  * What is the overall purpose of the code in this repository?

  * Is there an existing architecture that this code will be following

    or is there some new design that you are persuing (and needs to be

    document)?

  * Are there existing phosphor-dbus-interfaces that you will be

    implementing?  Are there new dbus interfaces you are proposing to

    implement the functionality you want from this repository?



--


I want to implement related functions for the bittware 250-SoC card.
For example: Sensor reading, VPD information, led control and Brick Protection mechanism.

We don't need to modify phosphor-dbus-interfaces.

Best Regards,
Ben



---------------------------------------------------------------------------------------------------------------------------------------------------------------
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. 
Any unauthorized review, use, copying or distribution of this email or the content of this email is strictly prohibited.
If you are not the intended recipient, you may reply to the sender and should delete this e-mail immediately.
---------------------------------------------------------------------------------------------------------------------------------------------------------------

[-- Attachment #2: Type: text/html, Size: 6789 bytes --]

Re: phosphor-bittware repository

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]

Hello Ben,

On Tue, May 12, 2020 at 09:09:50AM +0000, Ben_Pai@wistron.com wrote:

> I want to implement related functions for the bittware 250-SoC card.
> For example: Sensor reading, VPD information, led control and Brick
> Protection mechanism.

I looked briefly at the datasheet for this hardware [1].  It appears to
expose an SMBus interface for the features you mentioned.  The most
straight-forward way to get this implemented is to create a kernel
driver for most of the features you mentioned.  If you implement a
driver for this hardware that interacts with the hwmon, eeprom, and LED/GPIO
subsystems in the kernel(*), you'll be able to reuse a lot of existing
OpenBMC functionality without rewriting any userspace code.

- Sensor
    - Kernel: hwmon
    - Userspace: phosphor-hwmon or dbus-sensors
- VPD
    - Kernel: eeprom
    - Userspace: entity-manager (I think)
- LED control
    - Kernel: LED / GPIO
    - Userspace: phosphor-led-manager

The only part that wouldn't be covered would be the "Brick Protection".
We'd need to see some more information on how this is exposed but you
might be able to work it into the existing phosphor-bmc-code-mgmt
repository.  For power supplies, they did create a separate repository
(phosphor-psu-code-mgmt) but I think they relied on some kernel APIs for
doing part of the work.

(*) Depending on how the bittware hardware is implemented at an SMBus
    level you may end up with multiple smaller drivers (this is better).
    If there is a single SMBus address for all these functions, you'll
    likely end up with one big driver.

1. https://www.bittware.com/wp-content/uploads/datasheets/ds-250-soc.pdf

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: phosphor-bittware repository

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]

On Tue, May 19, 2020 at 06:47:48AM +0000, Ben_Pai@wistron.com wrote:
> Because the 250-soc card needs to adjust the io expander to get the relevant information (e.g. temperature, VPD ...).

Is this IO expander on the i2c bus itself, like a mux or hub, or is it
some specialized register set to switch between logic banks?  In either
case though, I don't know why you couldn't create a kernel driver for
controlling access to the various logic blocks.  If it is like an
i2c-mux, there is a number of implementations of that in the kernel
already.

> I think a dynamic detection function may be needed to handle the presence of the card and dynamically adjust the io expander.

I'm not sure what you mean by "dynamic detection function" here.  If you
just mean detecting the presence of the card by a GPIO or i2c probe
call, entity-manager can handle some of that for you, I believe.  You
don't need to put the card into the device tree directly, but you could
instead do some kind of probe call to ensure the device is present and
then manually 'bind' the i2c address to a kernel driver.  Entity-manager
already supports doing this.

> On the other hand, I just want to be able to integrate all the functions.

I think you're going to end up duplicating a lot of code that already exists
in the kernel this way and that is why I'm trying to steer you away from
it.  Just as a simple example on the sensors, we have two
implementations that can already consume Linux-hwmon data and give you
the dbus objects "for free".  If you go the direction of putting it all
in userspace, you're going to have to implement all the i2c activity,
hwmon-like polling, and dbus objects all yourself.  This isn't a trivial
amount of code.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

phosphor-bittware repository

[Ben_Pai]

[-- Attachment #1: Type: text/plain, Size: 2639 bytes --]

Hi Patrick



> I looked briefly at the datasheet for this hardware [1].  It appears to

> expose an SMBus interface for the features you mentioned.  The most

> straight-forward way to get this implemented is to create a kernel

> driver for most of the features you mentioned.  If you implement a

> driver for this hardware that interacts with the hwmon, eeprom, and LED/GPIO

> subsystems in the kernel(*), you'll be able to reuse a lot of existing

> OpenBMC functionality without rewriting any userspace code.

>

> - Sensor

>     - Kernel: hwmon

>     - Userspace: phosphor-hwmon or dbus-sensors

> - VPD

>     - Kernel: eeprom

>     - Userspace: entity-manager (I think)

> - LED control

>     - Kernel: LED / GPIO

>     - Userspace: phosphor-led-manager

>

> The only part that wouldn't be covered would be the "Brick Protection".

> We'd need to see some more information on how this is exposed but you

> might be able to work it into the existing phosphor-bmc-code-mgmt

> repository.  For power supplies, they did create a separate repository

> (phosphor-psu-code-mgmt) but I think they relied on some kernel APIs for

> doing part of the work.

>

> (*) Depending on how the bittware hardware is implemented at an SMBus

>     level you may end up with multiple smaller drivers (this is better).

>     If there is a single SMBus address for all these functions, you'll

>     likely end up with one big driver.

>

> 1. https://www.bittware.com/wp-content/uploads/datasheets/ds-250-soc.pdf


Sorry for late reply.



Because the 250-soc card needs to adjust the io expander to get the relevant information (e.g. temperature, VPD ...).

I think a dynamic detection function may be needed to handle the presence of the card and dynamically adjust the io expander.

On the other hand, I just want to be able to integrate all the functions.

Best Regards,
Ben



---------------------------------------------------------------------------------------------------------------------------------------------------------------
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. 
Any unauthorized review, use, copying or distribution of this email or the content of this email is strictly prohibited.
If you are not the intended recipient, you may reply to the sender and should delete this e-mail immediately.
---------------------------------------------------------------------------------------------------------------------------------------------------------------

[-- Attachment #2: Type: text/html, Size: 9734 bytes --]

Re: phosphor-bittware repository

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

Hello Ben,

On Thu, May 07, 2020 at 06:07:44AM +0000, Ben_Pai@wistron.com wrote:
> Could you please help to create a new repository for phosphor-bittware?

Out of curiousity for others who aren't aware of what 'bittware' is,
could you describe a little about this repository?  It seems to be a
hardware vendor, so it would be interesting to know what the BMC will be
doing with it.

Examples:
  * What is the overall purpose of the code in this repository?
  * Is there an existing architecture that this code will be following
    or is there some new design that you are persuing (and needs to be
    document)?
  * Are there existing phosphor-dbus-interfaces that you will be
    implementing?  Are there new dbus interfaces you are proposing to
    implement the functionality you want from this repository?

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

phosphor-bittware repository

[Ben_Pai]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

Hi Brad

Could you please help to create a new repository for phosphor-bittware?

Best Regards,
Ben


---------------------------------------------------------------------------------------------------------------------------------------------------------------
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. 
Any unauthorized review, use, copying or distribution of this email or the content of this email is strictly prohibited.
If you are not the intended recipient, you may reply to the sender and should delete this e-mail immediately.
---------------------------------------------------------------------------------------------------------------------------------------------------------------

[-- Attachment #2: Type: text/html, Size: 3630 bytes --]