summaryrefslogtreecommitdiffstats
path: root/drivers/video/fbdev/omap2
Commit message (Collapse)AuthorAgeFilesLines
* OMAPDSS: hdmi5: Remove callbacks for the old ASoC DAI driverJyri Sarha2014-12-011-113/+0
| | | | | | | | Removes the OMAP5 HDMI audio callbacks for the old external DAI driver. Signed-off-by: Jyri Sarha <jsarha@ti.com> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: hdmi4: Register ASoC platform device for omap hdmi audioJyri Sarha2014-12-011-0/+125
| | | | | | | | | Implements callbacks for OMAP HDMI audio platform driver and registers it in probe function. Unregistering is done in remove function. Signed-off-by: Jyri Sarha <jsarha@ti.com> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: hdmi4: Remove callbacks for the old ASoC DAI driverJyri Sarha2014-12-011-113/+0
| | | | | | | | Removes the OMAP4 HDMI audio callbacks for the old external DAI driver. Signed-off-by: Jyri Sarha <jsarha@ti.com> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: hdmi: Make hdmi_mode_has_audio() more user friedlyJyri Sarha2014-12-011-2/+2
| | | | | | | | | Make hdmi_mode_has_audio() more user friedly by taking hdmi_config as parameter. Signed-off-by: Jyri Sarha <jsarha@ti.com> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: Kconfig: Remove HDMI audio booleans from KconfigJyri Sarha2014-12-011-7/+0
| | | | | | | | | The booleans are not used anymore. Just select SND_OMAP_SOC_HDMI_AUDIO to enable OMAP HDMI audio support. Signed-off-by: Jyri Sarha <jsarha@ti.com> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: hdmi.h: Add members to hdmi drvdata for audio implementationJyri Sarha2014-11-261-0/+2
| | | | | | | Adds display_enabled flag and audio_abort_cb callback to struct hdmi. Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: hdmi: Add pdev pointer for audio_pdev in HDMI DRV dataJyri Sarha2014-11-261-0/+2
| | | | | | | This is used to store omap-hdmi-audio pdev for unregistering it. Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: hdmi: Make hdmi structure publicJyri Sarha2014-11-263-40/+30
| | | | | | | | Unify the private anonymous struct in hdmi4.c and hdmi5.c, name it as struct omap_hdmi, and make it public in hdmi.h. Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: hdmi_wp: Add function for getting audio dma addressJyri Sarha2014-11-262-0/+8
| | | | | | | The audio dma port is found in the hdmi_wp physical address space. Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: hdmi4_core: Remove unused hdmi4_audio_get_dma_port()Jyri Sarha2014-11-262-11/+0
| | | | | | | hdmi4_audio_get_dma_port() is unused and and broken. Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: hdmi: Remove most of OMAP[45]_DSS_HDMI_AUDIO ifdefsJyri Sarha2014-11-267-21/+1
| | | | | | | | | | It does not waste too many bytes to compile all audio related core functions always in with HDMI support. It should help readability and in keeping the audio code in working shape. Leave the options just for disabling and enabling the functionality in hdmi[45].c. Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum valueJyri Sarha2014-11-261-1/+2
| | | | | | | | | The OMAP5 HDMI audio implementation needs HDMI_AUDIO_LAYOUT_6CH in hdmi_core_audio_layout enum. I found the correct value from ti-linux 3.8 tree. Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: hdmi5_core: Initialize mandatory sample_order parameterJyri Sarha2014-11-261-0/+3
| | | | | | | | | The hdmi_wp_audio_config_format() expects sample_order of struct hdmi_audio_format to be initialized. The only allowed value is HDMI_AUDIO_SAMPLE_LEFT_FIRST. Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: hdmi_wp: Protect reserved bits in hdmi_wp_audio_config_format()Jyri Sarha2014-11-261-2/+6
| | | | | | | Only OMAP4 DSS has non reserved bits above 6th bit in HDMI_WP_AUDIO_CFG. Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: features: remove unused DSI PLL featuresTomi Valkeinen2014-11-122-49/+0
| | | | | | | | | Now that the DSS has the common DSS PLL, we no longer use the DSI PLL feature flags from dss_features.c. Remove all the unused feature flags. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: HDMI: use common DSS PLL supportTomi Valkeinen2014-11-124-214/+146
| | | | | | | | | | | Now that we have the common DSS PLL support, change HDMI to use it. This results in quite a lot of changes, but almost all of them are trivial name changes. The function to program the PLL settings can be removed from hdmi_pll.c, as the common PLL API contains the same functionality. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: HDMI: remove extra poweroffTomi Valkeinen2014-11-121-4/+0
| | | | | | | | | hdmi_pll_enable powers off the PLL as the first thing it does. Right after that, it enables the PLL powers. The initial power-off is pointless, so let's remove it. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: HDMI: split PLL enable & configTomi Valkeinen2014-11-124-9/+18
| | | | | | | | | | | At the moment we have one function, hdmi_pll_enable, which enables the PLL and writes the PLL configuration to registers. To make the HDMI PLL ahere to the DSS PLL API, split the hdmi_pll_enable into two parts: hdmi_pll_enable which enables the PLL HW, and hdmi_pll_set_config which writes the config. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: HDMI: store WP pointer to hdmi_pll_dataTomi Valkeinen2014-11-124-14/+23
| | | | | | | | | | | | HDMI PLL code needs the pointer to the WP block so that it can manage its power. Currently this is passed as a function parameter to hdmi_pll_enable and hdmi_pll_disable. To make the PLL function adhere to the DSS PLL API, we need to remove the WP parameter. This patch stores the WP pointer to hdmi_pll_data in hdmi_pll_init, so that it's available when needed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: HDMI: Remove HDMI PLL resetTomi Valkeinen2014-11-121-19/+0
| | | | | | | | | | | The SYSRESET bits in HDMI PLL do not reset the PLL itself, but only affect the power used for the PLL. Afaik there is no reason to use the SYSRESET bits, and we don't use it in the other PLLs, so let's remove the HDMI PLL reset to make the PLL code simpler and similar to other PLLs. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: HDMI: rewrite HDMI PLL calculation codeTomi Valkeinen2014-11-125-83/+71
| | | | | | | | | | | The code calculating HDMI PLL parameters has always been very confusing. Now that we are implementing a common PLL library for the DSS, it's important that the PLL code is understandable. This patch rewrites the calculation code, and removes a few hacks that were used there. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: HDMI5: disable interlace modesTomi Valkeinen2014-11-121-0/+4
| | | | | | | We don't support interlace modes properly on OMAP5+ HDMI, so we need to reject interlace timings. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: HDMI: fix setting REFSELTomi Valkeinen2014-11-122-12/+4
| | | | | | | | | Only OMAP5+ has REFSEL field, but at the moment it's set also on OMAP4. Fix this by adding a "has_refsel" field, and setting the REFSEL based on that. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DSI: use common DSS PLL supportTomi Valkeinen2014-11-124-489/+255
| | | | | | | | | | | | | | | Now that we have the common DSS PLL support, change DSI to use it. This results in quite a lot of changes, but almost all of them are trivial name changes. The functions to calculate and program the PLL settings can be removed from dsi.c, as the common PLL API contains the same functionality. We also need to create struct dss_pll_hw entries for PLL hardware features for different OMAP platforms, instead of using the dss_features.c as the old code does. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: Add common PLL codeTomi Valkeinen2014-11-123-1/+467
| | | | | | | | | | | | | | | OMAP DSS currently contains two different PLLs: DSI PLL (Type A PLL) and HDMI PLL (Type B PLL). When DRA7 support is added, we will also support Video PLLs (Type A). The driver currently handles all PLLs totally separately. This patch adds common DSS PLL code, which a) lets us have common code for the PLLs b) lets the users of the PLLs use a common API, instead of DSI API or HDMI API. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DSI: dsi_runtime_get/put in pll_initTomi Valkeinen2014-11-123-28/+9
| | | | | | | | | | When DPI uses the DSI PLL for pixel clock, the DPI code will call dsi_runtime_get/put to keep the DSI block enabled. A much simpler way to handle this is to do dsi_runtime_get/put in DSI's dsi_pll_init() and dsi_pll_uninit(), thus removing the need for DSI to call the runtime PM functions. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DSI: features: combine dsi & dispc hsdivsTomi Valkeinen2014-11-123-17/+11
| | | | | | | | | The HSDIV outputs of DSI PLL (and also other PLLs) all have the same bit width for the divider value. Simplify the code by merging HSDIV divider widths into one width. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DSI: turn hsdivs fields to arraysTomi Valkeinen2014-11-123-42/+42
| | | | | | | | | | | We are creating a common DSS PLL code, so having fixed DSI specific hsdiv fields in the clock information is not ok. This patch changes the hsdiv fields to arrays, so that we can use all the 4 possible hsdiv outputs (DSI only usees 2), and we have generic way to access the hsdivs. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DSI: rename clkin4ddr to clkdcoTomi Valkeinen2014-11-123-20/+20
| | | | | | | We are creating a common DSS PLL code, so rename 'clkin4ddr' field, which is DSI specific name, to 'clkdco' which is a generic name. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DSI: use struct copy instead of individual field copyTomi Valkeinen2014-11-121-11/+1
| | | | | | | | Now that dsi_clock_info only contains information about the PLL, we can just copy the whole struct when storing the clock information, instead of copying individual fields. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DSI: remove pll_locked fieldTomi Valkeinen2014-11-121-10/+0
| | | | | | | We have pll_locked field in struct dsi_data, but it doesn't have any meaningful use anymore, and can be removed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DSI: remove clkin from dsi_clock_infoTomi Valkeinen2014-11-123-11/+4
| | | | | | | | | | struct dsi_clock_info contains clkin field, which is the rate of the PLL's input clock. This field is not needed, as it can be easily retrieved by using the clk_get_rate(). This patch removes the clkin field. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DSI: separate LP clock info from dsi_clock_infoTomi Valkeinen2014-11-122-13/+19
| | | | | | | | | | | | struct dsi_clock_info represents the clocks handled by the DSI, mostly PLL related clocks. In an effort to create common PLL code, we need to remove all the non-PLL items from dsi_clock_info. This patch removes LP clock related fields from dsi_clock_info, and creates a new struct dsi_lp_clock_info for holding clock info for the LP clock. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DSI: always power on hsclk & hsdivTomi Valkeinen2014-11-123-26/+7
| | | | | | | | | | | | | The DSS PLL has support to power on the PLL's highspeed clock output and HSDIV output separately. In practice both need to powered on, as in most OMAP's that's the only working configuration. We already do that in dsi_pll_init(), by overriding the passed arguments so that both are always powered. Simplify the code by removing the support for choosing which outputs to power on. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DSI: remove unused hsdiv wait funcsTomi Valkeinen2014-11-123-38/+0
| | | | | | | | | With the previous patch "OMAPDSS: DSI: wait for hsdiv clocks when enabling PLL", dsi_wait_pll_hsdiv_dispc_active and dsi_wait_pll_hsdiv_dsi_active are no longer needed, so they and the callers can be removed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DSI: wait for hsdiv clocks when enabling PLLTomi Valkeinen2014-11-121-0/+21
| | | | | | | | | | | | | At the moment we have two functions to wait for the HSDIV clocks to get active, dsi_wait_pll_hsdiv_dispc_active and dsi_wait_pll_hsdiv_dsi_active. Instead of such inconvenient functions, let's just make sure that the hsdiv clocks are active after the pll has been enabled. This patch adds code to dsi_pll_set_clock_div() to wait until HSDIV clocks are active. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DSS: add a param to dpi_select_source which specifies it's port numberArchit Taneja2014-11-123-8/+8
| | | | | | | | | Add a 'port' parameter in dpi_select_source. The param tells the port number of the DPI instance that we want to configure. We use this number to select the overlay manager for that DPI instance. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DPI: Add support for multiple instancesArchit Taneja2014-11-121-3/+23
| | | | | | | | | | | | | Register DPI outputs, and assign the port_num to them as specified by the 'reg' property in the DPI ports in DT. To support multiple DPI instances, dpi_get_channel needs to take the DPI instance's port number to get the corresponding channel. Make it take this argument. We just pass 0 in the non-DT path, since we don't support multiple instances in the non-DT case. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DT: Get source endpoint by matching reg-idArchit Taneja2014-11-125-21/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In omapdss_of_find_source_for_first_ep, we retrieve a source endpoint's DT node, and then see what omapdss output has the matching device_node pointer in omap_dss_find_output_by_node. For all DPI and SDI outputs, the device_node pointer is set as the parent's DSS device_node pointer. If the source is one of these outputs, the above method won't work. To get the correct output for ports within DSS(and in other cases in the future, where multiple ports might be under one device), we require additional information which is exclusive to the output port. We create a new field in omap_dss_device called 'port_num', this provides port number of the output port corresponding to this device. When searching for the source endpoint in DT, we extract the 'reg' property from the port corresponding to the endpoint source. From the list of registered outputs, we pick out that output which has both dev->of_node and port_num matching with the device_node pointer and 'reg' of the source endpoint node from DT. For encoder blocks(the ones which have both an input and output port), we need to set the port_num as the 'reg' property for the output port as defined in the DT bindings. We set port_num to 1 in the tfp410 and tpd12s015 encoder drivers. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DSS: init dss ports cleanlyArchit Taneja2014-11-123-16/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | The init/uninit port functions are used to set up the DPI and SDI outputs under the dss platform device. A 'reg' property is used to determine the port number of the output. This tells us whether the port is DPI or SDI for OMAP34xx DSS revision. For other DSS revisions, we only have DPI outputs under the dss platform device. For multiple DPI output instances(introduced in DRA7xx DSS), we will use the the port number to specify which DPI output instance is being inited. The current functions work fine if there is only one DPI output instance in DSS. For multiple DPI instances, it would get complicated to figure out whether port number was used to specify whether the output is SDI, or another DPI instance. We create a list of port types supported for each DSS rev, with the index of the port in the list specifying the port number of the output for that DSS revision. This allows us to have a more generic way to init/uninit ports within DSS, and also support multiple DPI ports. We make the uninit_port functions iterative since we will have multiple DPI ports to uninit in the future. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DPI: Store dpi_data pointer in the DT port's dataArchit Taneja2014-11-123-8/+42
| | | | | | | | | | | | | | | | | | | | | | DPI and SDI ports are backed by only one parent DSS device. We don't have a corresponding platform_device for ports under DSS. In order to support multiple instances of DPI, we need to pass the driver data pointer through the DPI port's private data ('data' member in device_node struct). dpi_init_output/dpi_uninit_output are untouched and only used for non-DT case, these are called when the DPI platform device probed/removed. These funcs will be removed when non-DT mode is removed. dpi_init_output_port/dpi_uninit_output_port are created and used for the DT path, called when DSS inits/uninits it's ports. These new functions retrieve the dpi_data pointer from 'port->data', and not from the platform device's data(pdev->dev) like in the non-DT path. We add some code in dss_uninit_ports() to pass a pointer to the DPI port in dpi_uninit_port(). Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DPI: Allocate driver dataArchit Taneja2014-11-123-18/+36
| | | | | | | | | | | | | | | | | | | | Allocate driver data(dpi_data) for each DPI instance. It's allocated in omap_dpi_probe() when DT isn't used, and in dpi_init_port() when DT is used. The dpi_data struct instance is no longer global. In the case of DPI ops, it's retrieved from dpi_get_data_from_dssdev(). 'dssdev' passed by the connected encoder/panel driver is a pointer to the 'output' member in dpi_data, and thus can be used to get the DPI instance's driver data. In the case of probe/ini_port functions, it's set as DPI/DSS device's private data embedded in the platform_device struct. Having dpi_data as private data of the platform device will not work for multiple DPI instances in the DT case. This is because there is no corresponding platform_device for DPI or SDI, they exist only as ports under the parent DSS platform_device in the DT case. The DPI port's private data('data' member in device_node struct) will later be used to store dpi_data. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DPI: Use DPI driver dataArchit Taneja2014-11-121-80/+107
| | | | | | | | | | | | | | | DPI related data is currently a static global struct parameter. It is accessed directly by functions in the driver. This method won't work if we want the driver to support multiple DPI instances. Create struct dpi_data, and pass its pointer to functions which need to use it. We still have a static instance defined for dpi_data, which is accessed by top level DPI ops. This will be removed when the driver dynamically allocates dpi_data for each DPI instance. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* omap: dss: connector-analog-tv: Add missing module device tableMarek Belisko2014-10-301-0/+2
| | | | | | | | Without that fix connector-analog-tv driver isn't probed when compiled as module. Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DSI: Fix PLL_SELFEQDCO field widthTomi Valkeinen2014-10-221-1/+1
| | | | | | | | PLL_SELFREQDCO bitfield is from bit 3 to 1, but the driver writes bits from 4 to 1. The bit 4 is 'reserved', so this probably should not cause any issues, but it's better to fix it. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: fix dispc register dump for preload & mflagTomi Valkeinen2014-10-221-4/+3
| | | | | | | | | Preload register is dumped twice for video overlays and mflag register is not dumped for GFX. Fix the register dump. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DISPC: fix mflag offsetTomi Valkeinen2014-10-221-2/+1
| | | | | | The register offset for DISPC_OVL_MFLAG_THRESHOLD is wrong, fix it. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: HDMI: fix regsd writeTomi Valkeinen2014-10-221-5/+4
| | | | | | | | HDMI PLL's REGSD field is only set by the driver if the PLL's output clock is over 1GHz. This is clearly an error, as REGSD should be set always. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: HDMI: fix PLL GO bit handlingTomi Valkeinen2014-10-221-2/+2
| | | | | | | | | | | | | | | The PLL settings are committed by setting GO bit, which is then cleared by the HW when the settings have been taken into use. The current PLL code handles this wrong: instead of waiting for the bit to be cleared, it waits for the bit to be set. Usually, the bit is always set, as the CPU has just set it before. However, if the CPU takes enough time between setting the GO bit and checking it, the HW may already have cleared the bit and this leads to timeout error. Fix the wait to check the bit properly. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPFB: fix releasing overlaysTomi Valkeinen2014-10-221-0/+3
| | | | | | | | | | | | omapfb disables all the overlays when freeing resources, but it should also remove those overlays from overlay managers. Not doing so causes a crash if omapfb is unbound and bound, or omapfb module is removed and loaded, while keeping omapdss around. Fix this by calling unset_manager() for all overlays. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
OpenPOWER on IntegriCloud