openbmc Digest, Vol 31, Issue 6

Chandrasekar R chandrasekarr at ami.com
Wed Mar 7 01:15:37 AEDT 2018


Hi Ed,

We, from American Megatrends, would like to participate in OpenBMC Redfish Working Group discussions. We were able to join the call through phone yesterday from OpenBMC Github Wiki link. But we did not have skype/lync access URL in that Wiki. Is it possible for you to share it?

Thanks
Chandrasekar Rathineswaran
American Megatrends Inc. 
________________________________________
From: openbmc [openbmc-bounces+chandrasekarr=ami.com at lists.ozlabs.org] on behalf of openbmc-request at lists.ozlabs.org [openbmc-request at lists.ozlabs.org]
Sent: Friday, March 02, 2018 8:00 PM
To: openbmc at lists.ozlabs.org
Subject: openbmc Digest, Vol 31, Issue 6

Send openbmc mailing list submissions to
        openbmc at lists.ozlabs.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.ozlabs.org/listinfo/openbmc
or, via email, send a message with subject or body 'help' to
        openbmc-request at lists.ozlabs.org

You can reach the person managing the list at
        openbmc-owner at lists.ozlabs.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openbmc digest..."


Today's Topics:

   1. Re: openbmc Digest, Vol 30, Issue 51 (James Feist)
   2. RE: OpenBMC Redfish Working Group - meeting times open
      discussion (Tanous, Ed)
   3. Re: [PATCH v10 2/3] NPCM750: add clock tree doc and binding
      (Rob Herring)


----------------------------------------------------------------------

Message: 1
Date: Fri, 2 Mar 2018 10:17:43 -0800
From: James Feist <james.feist at linux.intel.com>
To: guhan balasubramanian <guhan.sac at gmail.com>,
        openbmc at lists.ozlabs.org
Subject: Re: openbmc Digest, Vol 30, Issue 51
Message-ID: <e19241a8-e80a-e22d-c47b-638bbf0365a1 at linux.intel.com>
Content-Type: text/plain; charset=utf-8; format=flowed

- Accidentally dropped Guhan's email, resending.

Hi Guhan,

I don't believe there is a way to do this today, but I have posted an
RFC to dynamically collect the SDR info from dbus that you might be
interested here: https://gerrit.openbmc-project.xyz/#/c/8521/

The ipmi maintainers I believe like this approach and plan on moving
towards this once this code is integrated into the current ipmi libraries.

Thanks,

James


On 03/01/2018 05:49 PM, guhan balasubramanian wrote:
> Hi,
>
> Currently in the IPMID (net and host) shared libraries, SDR and sensor
> ipmi commands are addressed by querying the "IdInfoMap" data structure
> (sensorhandler.cpp). This data structure is being filled up using
> phosphor-sensor-inventory/config.yaml, during build time (as mentioned
> by Patrick and Lei).
>
> Assuming that we are not able to pre-fill the config yaml, is there a
> way in the current implementation, where we can add sensors to this
> sensors "IdInfoMap" data structure dynamically during run time?
>
> Thanks,
> Guhan
>
>     Date: Wed, 14 Feb 2018 10:36:23 -0800
>     From: Patrick Venture <venture at google.com <mailto:venture at google.com>>
>     To: Lei YU <mine260309 at gmail.com <mailto:mine260309 at gmail.com>>
>     Cc: "Sachin Naik (sachnaik)" <sachnaik at cisco.com
>     <mailto:sachnaik at cisco.com>>,
>              "openbmc at lists.ozlabs.org
>     <mailto:openbmc at lists.ozlabs.org>" <openbmc at lists.ozlabs.org
>     <mailto:openbmc at lists.ozlabs.org>>
>     Subject: Re: Porting hwmon sensors to openBMC
>     Message-ID:
>
>     <CAO=notwMecK=GhvVUtgeVUZFV38K71Q5SSF0TeCS0CxY2W+axw at mail.gmail.com
>     <mailto:GhvVUtgeVUZFV38K71Q5SSF0TeCS0CxY2W%2Baxw at mail.gmail.com>>
>     Content-Type: text/plain; charset="UTF-8"
>
>     Lei is correct. If you want, however, to read the sensors over IPMI
>     you'll need to add a yaml configuration for the sensors as well for
>     phosphor-host-ipmid.
>     See
>     https://github.com/openbmc/openbmc/blob/master/meta-openbmc-machines/meta-x86/meta-quanta/meta-q71l/recipes-phosphor/ipmi/q71l-ipmi-sensor-map/config.yaml
>     <https://github.com/openbmc/openbmc/blob/master/meta-openbmc-machines/meta-x86/meta-quanta/meta-q71l/recipes-phosphor/ipmi/q71l-ipmi-sensor-map/config.yaml>
>     for an example.
>
>     On Tue, Jan 23, 2018 at 11:04 PM, Lei YU <mine260309 at gmail.com
>     <mailto:mine260309 at gmail.com>> wrote:
>      > On Tue, Jan 23, 2018 at 3:33 PM, Sachin Naik (sachnaik)
>      > <sachnaik at cisco.com <mailto:sachnaik at cisco.com>> wrote:
>      >> Hi All
>      >>
>      >> I am porting a new board to openbmc.
>      >> I have question on mapping hwmon type sensors to Dbus
>      >>
>      >> So far I have created machine layer and added U-boot config,
>     Kernel config and device tree. In kernel config I have enabled lm75
>     hwmon driver for LM75 temperature device. Corresponding entry added
>     in device tree.
>      >>
>      >> Right now I have created hwmon temperature sensors entry in our
>     machine layer by extending
>     recipes-phosphor/sensors/phosphor-hwmon%.bbappend
>      >> and created conf file with temperature sensors label.
>      >>
>      >> Now my question is how do implement/map dbus temperature sensor
>     value interface to our hwmon temperature sensors? Is above
>     implementation is enough or it requires
>      >> Some mapping for dbus to hwmon instance?
>      >
>      > After you added config files for the temperature sensors with
>      > phosphor-hwmon%.bbappend, phosphor-hwmon will read from
>      > hwmon instance and create dbus objects at
>      > /xyz/openbmc_project/sensors/, which will at least have "Value",
>      > “Scale" and "Unit" properties.
>      >
>      > I do not think it requires other configs, unless I misunderstand
>      > your case?
>      >
>      >>
>      >> Thanks and regards
>      >> Sachin
>      >>
>      >>
>


------------------------------

Message: 2
Date: Fri, 2 Mar 2018 22:08:25 +0000
From: "Tanous, Ed" <ed.tanous at intel.com>
To: Hariharasubramanian Ramasubramanian <hramasub at in.ibm.com>
Cc: "Michael.E.Brown at dell.com" <Michael.E.Brown at dell.com>,
        "openbmc at lists.ozlabs.org" <openbmc at lists.ozlabs.org>
Subject: RE: OpenBMC Redfish Working Group - meeting times open
        discussion
Message-ID:
        <7E9441B1E5EFFD4681F54958E82169932F6691A6 at ORSMSX114.amr.corp.intel.com>

Content-Type: text/plain; charset="us-ascii"

Yes, the final meeting time will remain Mondays at 4PM.

The data came back as follows:
Mondays 4PM CST: 8 votes
Thursdays 9AM CST: 5 votes
Thursdays 12PM CST: 5 votes
Friday 8am CST: 4 votes
Mondays 9am CST: 6 votes

Monday at 4PM CST is also the time that the highest number of people that reported they have contributed open source redfish code were available.

Pradeep and Hariharasubramanian were the only ones not available during that time period.  I don't want you to feel like you are being excluded, but there were no times that worked for everyone.  I will do my best to take judicious notes, and will post them publically.  IF you have agenda items that you guys would like me to bring up on your behalf, I'm happy to have a phone call with you guys at a time that's convenient to make sure your viewpoints are heard in the meeting.

We can re-evaluate the meeting time in the March 26th meeting, and see if the results have changed.

Based on this, the next meeting will be 3/5/18 at 4PM CST.

Suggested meeting agenda and call for topics to be sent out in another email shortly

-Ed

From: Hariharasubramanian Ramasubramanian [mailto:hramasub at in.ibm.com]
Sent: Thursday, March 1, 2018 11:38 PM
To: Tanous, Ed <ed.tanous at intel.com>
Cc: Michael.E.Brown at dell.com; openbmc at lists.ozlabs.org
Subject: RE: OpenBMC Redfish Working Group - meeting times open discussion

"Tanous, Ed" <ed.tanous at intel.com> wrote on 02/28/2018 04:56:45 AM:

> From: "Tanous, Ed" <ed.tanous at intel.com>
> To: "Michael.E.Brown at dell.com" <Michael.E.Brown at dell.com>,
> "hramasub at in.ibm.com" <hramasub at in.ibm.com>
> Cc: "openbmc at lists.ozlabs.org" <openbmc at lists.ozlabs.org>
> Date: 02/28/2018 04:56 AM
> Subject: RE: OpenBMC Redfish Working Group - meeting times open discussion
>
> >
> > Add a Monday 9am CST (7am PST) option so that I can vote for that. :)
> > --
> > Michael
> >
>
> Added.
>

Do we have enough votes / consensus on the time ?


------------------------------

Message: 3
Date: Fri, 2 Mar 2018 16:12:36 -0600
From: Rob Herring <robh at kernel.org>
To: Tali Perry <tali.perry1 at gmail.com>
Cc: brendanhiggins at google.com, mark.rutland at arm.com,
        linux at armlinux.org.uk, avifishman70 at gmail.com, tmaimon77 at gmail.com,
        raltherr at google.com, mturquette at baylibre.com, sboyd at codeaurora.org,
        devicetree at vger.kernel.org, linux-kernel at vger.kernel.org,
        linux-arm-kernel at lists.infradead.org, openbmc at lists.ozlabs.org,
        linux-clk at vger.kernel.org
Subject: Re: [PATCH v10 2/3] NPCM750: add clock tree doc and binding
Message-ID: <20180302221236.qsxooi5l53wx6lby at rob-hp-laptop>
Content-Type: text/plain; charset=us-ascii

On Sun, Feb 25, 2018 at 12:12:18PM +0200, Tali Perry wrote:
>
Need a commit msg.

The subject should be "dt-bindings: clock: ..."

> Signed-off-by: Tali Perry <tali.perry1 at gmail.com>
>
> ---
>  .../bindings/clock/nuvoton,npcm750-clk.txt         | 100 +++++++++++++++++++++
>  include/dt-bindings/clock/nuvoton,npcm7xx-clock.h  |  44 +++++++++
>  2 files changed, 144 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/nuvoton,npcm750-clk.txt
>  create mode 100644 include/dt-bindings/clock/nuvoton,npcm7xx-clock.h
>
> diff --git a/Documentation/devicetree/bindings/clock/nuvoton,npcm750-clk.txt b/Documentation/devicetree/bindings/clock/nuvoton,npcm750-clk.txt
> new file mode 100644
> index 000000000000..dd17b86bd577
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/nuvoton,npcm750-clk.txt
> @@ -0,0 +1,100 @@
> +* Nuvoton NPCM7XX Clock Controller
> +
> +Nuvoton Poleg BMC NPCM7XX contains an integrated clock controller, which
> +generates and supplies clocks to all modules within the BMC.
> +
> +External clocks:
> +
> +There are six fixed clocks that are generated outside the BMC. All clocks are of
> +a known fixed value that cannot be changed. clk_refclk, clk_mcbypck and
> +clk_sysbypck are inputs to the clock controller.
> +clk_rg1refck, clk_rg2refck and clk_xin are external clocks suppling the
> +network. They are set on the device tree, but not used by the clock module. The
> +network devices use them directly.
> +Example can be found below.
> +
> +All available clocks are defined as preprocessor macros in:
> +dt-bindings/clock/nuvoton,npcm7xx-clock.h
> +and can be reused as DT sources.
> +
> +Required Properties of clock controller:
> +
> +     - compatible: "nuvoton,npcm750-clk" : for clock controller of Nuvoton
> +               Poleg BMC NPCM750
> +
> +     - reg: physical base address of the clock controller and length of
> +             memory mapped region.
> +
> +     - #clock-cells: should be 1.
> +
> +Example: Clock controller node:
> +
> +     clk: clock-controller at f0801000 {
> +             compatible = "nuvoton,npcm750-clk";
> +             #clock-cells = <1>;
> +             reg = <0xf0801000 0x1000>;
> +             clock-names = "refclk", "sysbypck", "mcbypck";
> +             clocks = <&clk_refclk>, <&clk_sysbypck>, <&clk_mcbypck>;
> +     };
> +
> +Example: Required external clocks for network:
> +
> +     /* external reference clock */
> +     clk_refclk: clk-refclk {
> +             compatible = "fixed-clock";
> +             #clock-cells = <0>;
> +             clock-frequency = <25000000>;
> +             clock-output-names = "refclk";
> +     };
> +
> +     /* external reference clock for cpu. float in normal operation */
> +     clk_sysbypck: clk-sysbypck {
> +             compatible = "fixed-clock";
> +             #clock-cells = <0>;
> +             clock-frequency = <800000000>;
> +             clock-output-names = "sysbypck";
> +     };
> +
> +     /* external reference clock for MC. float in normal operation */
> +     clk_mcbypck: clk-mcbypck {
> +             compatible = "fixed-clock";
> +             #clock-cells = <0>;
> +             clock-frequency = <800000000>;
> +             clock-output-names = "mcbypck";
> +     };
> +
> +      /* external clock signal rg1refck, supplied by the phy */
> +     clk_rg1refck: clk-rg1refck {
> +             compatible = "fixed-clock";
> +             #clock-cells = <0>;
> +             clock-frequency = <125000000>;
> +             clock-output-names = "clk_rg1refck";
> +     };
> +
> +      /* external clock signal rg2refck, supplied by the phy */
> +     clk_rg2refck: clk-rg2refck {
> +             compatible = "fixed-clock";
> +             #clock-cells = <0>;
> +             clock-frequency = <125000000>;
> +             clock-output-names = "clk_rg2refck";
> +     };
> +
> +     clk_xin: clk-xin {
> +             compatible = "fixed-clock";
> +             #clock-cells = <0>;
> +             clock-frequency = <50000000>;
> +             clock-output-names = "clk_xin";
> +     };
> +
> +
> +Example: GMAC controller node that consumes two clocks: a generated clk by the
> +clock controller and a fixed clock from DT (clk_rg1refck).
> +
> +     ethernet0: eth at f0802000 {

ethernet at ...

> +             compatible = "snps,dwmac";
> +             reg = <0xf0802000 0x2000>;
> +             interrupts = <0 14 4>;
> +             interrupt-names = "macirq";
> +             clocks  = <&clk_rg1refck>, <&clk NPCM7XX_CLK_AHB>;
> +             clock-names = "stmmaceth", "clk_gmac";
> +     };
> diff --git a/include/dt-bindings/clock/nuvoton,npcm7xx-clock.h b/include/dt-bindings/clock/nuvoton,npcm7xx-clock.h
> new file mode 100644
> index 000000000000..f21522605b94
> --- /dev/null
> +++ b/include/dt-bindings/clock/nuvoton,npcm7xx-clock.h
> @@ -0,0 +1,44 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Nuvoton NPCM7xx Clock Generator binding
> + * clock binding number for all clocks supportted by nuvoton,npcm7xx-clk
> + *
> + * Copyright (C) 2018 Nuvoton Technologies tali.perry at nuvoton.com
> + *
> + */
> +
> +#ifndef __DT_BINDINGS_CLOCK_NPCM7XX_H
> +#define __DT_BINDINGS_CLOCK_NPCM7XX_H
> +
> +
> +#define NPCM7XX_CLK_CPU 0
> +#define NPCM7XX_CLK_GFX_PIXEL 1
> +#define NPCM7XX_CLK_MC 2
> +#define NPCM7XX_CLK_ADC 3
> +#define NPCM7XX_CLK_AHB 4
> +#define NPCM7XX_CLK_TIMER 5
> +#define NPCM7XX_CLK_UART 6
> +#define NPCM7XX_CLK_MMC  7
> +#define NPCM7XX_CLK_SPI3 8
> +#define NPCM7XX_CLK_PCI  9
> +#define NPCM7XX_CLK_AXI 10
> +#define NPCM7XX_CLK_APB4 11
> +#define NPCM7XX_CLK_APB3 12
> +#define NPCM7XX_CLK_APB2 13
> +#define NPCM7XX_CLK_APB1 14
> +#define NPCM7XX_CLK_APB5 15
> +#define NPCM7XX_CLK_CLKOUT 16
> +#define NPCM7XX_CLK_GFX  17
> +#define NPCM7XX_CLK_SU   18
> +#define NPCM7XX_CLK_SU48 19
> +#define NPCM7XX_CLK_SDHC 20
> +#define NPCM7XX_CLK_SPI0 21
> +#define NPCM7XX_CLK_SPIX 22
> +
> +#define NPCM7XX_CLK_REFCLK 23
> +#define NPCM7XX_CLK_SYSBYPCK 24
> +#define NPCM7XX_CLK_MCBYPCK 25
> +
> +#define NPCM7XX_NUM_CLOCKS    (NPCM7XX_CLK_MCBYPCK+1)
> +
> +#endif
> --
> 2.14.1
>


End of openbmc Digest, Vol 31, Issue 6
**************************************

Please consider the environment before printing this email.

The information contained in this message may be confidential and proprietary to American Megatrends, Inc.  This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited.  Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.


More information about the openbmc mailing list