Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1241166 > unrolled thread

Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver

Started byYakir Yang <ykk@rock-chips.com>
First post2015-10-07 08:30 +0200
Last post2015-10-14 10:20 +0200
Articles 10 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver Yakir Yang <ykk@rock-chips.com> - 2015-10-07 08:30 +0200
    Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver Javier Martinez Canillas <javier@osg.samsung.com> - 2015-10-07 10:50 +0200
      Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver Yakir Yang <ykk@rock-chips.com> - 2015-10-07 11:10 +0200
        Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver Javier Martinez Canillas <javier@osg.samsung.com> - 2015-10-07 11:30 +0200
          Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver Javier Martinez Canillas <javier@osg.samsung.com> - 2015-10-07 13:30 +0200
            Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver Yakir Yang <ykk@rock-chips.com> - 2015-10-08 02:50 +0200
              Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver Yakir Yang <ykk@rock-chips.com> - 2015-10-10 16:40 +0200
                Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver Javier Martinez Canillas <javier@osg.samsung.com> - 2015-10-13 11:30 +0200
                  Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver Yakir Yang <ykk@rock-chips.com> - 2015-10-13 16:00 +0200
                    Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver Javier Martinez Canillas <javier@osg.samsung.com> - 2015-10-14 10:20 +0200

#1241166 — Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver

FromYakir Yang <ykk@rock-chips.com>
Date2015-10-07 08:30 +0200
SubjectRe: [PATCH v5 0/17] Add Analogix Core Display Port Driver
Message-ID<qgQoF-54m-1@gated-at.bofh.it>
Hi all,

Friendly ping.....   :)


Best regards,
- Yakir


On 09/22/2015 03:20 PM, Yakir Yang wrote:
> Hi all,
>
>     The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
> share the same IP, so a lot of parts can be re-used. I split the common
> code into bridge directory, then rk3288 and exynos only need to keep
> some platform code. Cause I can't find the exact IP name of exynos dp
> controller, so I decide to name dp core driver with "analogix" which I
> find in rk3288 eDP TRM :)
>
> This time I create this version on linux-next branch (tag is next-20150918),
> and also applied this version to Heiko github eDP branch to verify the function.
> (https://github.com/mmind/linux-rockchip/tree/tmp/edp-with-veyron)
> Glad to say my chromebook "cnm,n116bgeea2" eDP panel just lighted rightly on
> Heiko branch. And after back port this series to chromeos-3.14 tree, my rk3288
> SDK board still can light my 2K DisplayPort monitor. So this time would be okay
> on mainline kernel and chromeos-3.14 tree. ;)
>
> Due to no Exynos board in my side, so I haven't verified the eDP function on
> samsung platform, I only ensure that there are no obvious compiled error. Any
> help would be greatly appreciated. :)
>
> Thanks,
> - Yakir
>
> Changes in v5:
> - Correct the check condition of gpio_is_valid when driver try to get
>    the "hpd-gpios" DT propery. (Heiko)
> - Move the platform attach callback in the front of core driver bridge
>    attch function. Cause once platform failed at attach, core driver should
>    still failed, so no need to init connector before platform attached (Krzysztof)
> - Keep code style no changes with the previous exynos_dp_code.c in this
>    patch, and update commit message about the new export symbol (Krzysztof)
> - Gather the device type patch (v4 11/16) into this one. (Krzysztof)
> - leave out the connector registration to analogix platform driver. (Thierry)
> - Resequence this patch after analogix_dp driver have been split
>    from exynos_dp code, and rephrase reasonable commit message, and
>    remove some controversial style (Krzysztof)
>      -		analogix_dp_write_byte_to_dpcd(
>      - 				dp, DP_TEST_RESPONSE,
>      +		analogix_dp_write_byte_to_dpcd(dp,
>      +				DP_TEST_RESPONSE,
> 				DP_TEST_EDID_CHECKSUM_WRITE);
> - Switch video timing type to "u32", so driver could use "of_property_read_u32"
>    to get the backword timing values. Krzysztof suggest me that driver could use
>    the "of_property_read_bool" to get backword timing values, but that interfacs
>    would modify the original drm_display_mode timing directly (whether those
>    properties exists or not).
> - Correct the misspell in commit message. (Krzysztof)
> - Remove the empty line at the end of document, and correct the endpoint
>    numbers in the example DT node, and remove the regulator iomux setting
>    in driver code while using the pinctl in devicetree instead. (Heiko)
> - Add device type declared, cause the previous "platform device type
>    support (v4 11/16)" already merge into (v5 02/14).
> - Implement connector registration code. (Thierry)
> - Split binding doc's from driver changes. (Rob)
> - Add eDP hotplug pinctrl property. (Heiko)
> - Remove "reg" DT property, cause driver could poweron/poweroff phy via
>    the exist "grf" syscon already. And rename the example DT node from
>    "edp_phy: phy@ff770274" to "edp_phy: edp-phy" directly. (Heiko)
> - Add deivce_node at the front of driver, update phy_ops type from "static
>    struct" to "static const struct". And correct the input paramters of
>    devm_phy_create() interfaces. (Heiko)
> - Split binding doc's from driver changes. (Rob)
> - Update the rockchip,grf explain in document, and correct the clock required
>    elemets in document. (Rob & Heiko)
> - Fix compiled error (Heiko)
> - Using the connector display info message to configure eDP driver input
>    video mode, but hard code CRTC video output mode to RGBaaa.
>
> Changes in v4:
> - Update "analogix,hpd-gpios" to "hpd-gpios" DT propery. (Rob)
> - Rename "analogix_dp-exynos.c" file name to "exynos_dp.c" (Jingoo)
> - Create a separate folder for analogix code in bridge/ (Archit)
> - Update commit message more readable. (Jingoo)
> - Adjust the order from 05 to 04
> - Provide backword compatibility with samsung. (Krzysztof)
> - Split all DTS changes, and provide backward compatibility. Mark old
>    properties as deprecated but still support them. (Krzysztof)
> - Update "analogix,hpd-gpio" to "hpd-gpios" prop name. (Rob)
> - Deprecated some properties which could parsed from Edid/Mode/DPCD. (Thierry)
>      "analogix,color-space" & "analogix,color-depth"   &
>      "analogix,link-rate"   & "analogix,lane-count"    &
>      "analogix,ycbcr-coeff" & "analogix,dynamic-range" &
>      "vsync-active-high"    & "hsync-active-high"      & "interlaces"
> - Separate all DTS changes to a separate patch. (Krzysztof)
> - Remove some deprecated DT properties in rockchip dp document.
> - Add commit message, and remove the redundant rockchip_dp_phy_init()
>    function, move those code to probe() method. And remove driver .owner
>    number. (Kishon)
> - Seprate the link-rate and lane-count limit out with the device_type
>    flag. (Thierry)
> - Take Jingoo suggest, add commit messages.
> - Call drm_panel_prepare() in .get_modes function, ensure panel should
>    power on before driver try to read edid message.
>
> Changes in v3:
> - Move exynos's video_timing code to analogix_dp-exynos platform driver,
>    add get_modes method to struct analogix_dp_plat_data. (Thierry)
> - Rename some "samsung*" dts propery to "analogix*". (Heiko)
> - The link_rate and lane_count shouldn't config to the DT property value
>    directly, but we can take those as hardware limite. For example, RK3288
>    only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would
>    like "link-rate = 0x0a" "lane-count = 4". (Thierry)
> - Dynamic parse video timing info from struct drm_display_mode and
>    struct drm_display_info. (Thierry)
> - Add devicetree binding documents. (Heiko)
> - Remove sync pol & colorimetry properies from the new analogix dp driver
>    devicetree binding. (Thierry)
> - Update the exist exynos dtsi file with the latest DP DT properies.
> - Leave "sclk_edp_24m" to rockchip dp phy driver which name to "24m",
>    and leave "sclk_edp" to analogix dp core driver which name to "dp",
>    and leave "pclk_edp" to rockchip dp platform driver which name to
>    "pclk". (Thierry & Heiko)
> - Add devicetree binding document. (Heiko)
> - Remove "rockchip,panel" DT property, take use of remote point to get panel
>    node. (Heiko)
> - Add the new function point dp_platdata->get_modes() init.
> - Suggest, add rockchip dp phy driver, collect the phy clocks and
>    power control. (Heiko)
> - Add "analogix,need-force-hpd" to indicate whether driver need foce
>    hpd when hpd detect failed.
> - move dp hpd detect to connector detect function.
> - Add edid modes parse support
>
> Changes in v2:
> - Keep author name list no changed (Jingoo)
> - Remove new copyright (Jingoo)
> - Fix compiled failed due to analogix_dp_device misspell
> - Improved commit message more readable, and avoid using some
>    uncommon style like bellow: (Joe Preches)
>      -  retval = exynos_dp_read_bytes_from_i2c(...
>    				  ...);
>      +  retval =
>      +  exynos_dp_read_bytes_from_i2c(......);
> - Get panel node with remote-endpoint method, and create devicetree binding
>    for driver. (Heiko)
> - Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
>    leave those clock to rockchip dp phy driver.
> - Fix compile failed dut to phy_pd_addr variable misspell error
>
> Mark Yao (1):
>    drm: rockchip: vop: add bpc and color mode setting
>
> Yakir Yang (16):
>    drm: exynos: dp: convert to drm bridge mode
>    drm: bridge: analogix/dp: split exynos dp driver to bridge directory
>    drm: bridge: analogix/dp: fix some obvious code style
>    drm: bridge: analogix/dp: remove duplicate configuration of link rate
>      and link count
>    drm: bridge: analogix/dp: dynamic parse sync_pol & interlace &
>      dynamic_range
>    Documentation: drm/bridge: add document for analogix_dp
>    ARM: dts: exynos/dp: remove some properties that deprecated by
>      analogix_dp driver
>    drm: rockchip: dp: add rockchip platform dp driver
>    Documentation: drm/bridge: add document for analogix_dp
>    phy: Add driver for rockchip Display Port PHY
>    Documentation: phy: add document for rockchip dp phy
>    drm: bridge: analogix/dp: add some rk3288 special registers setting
>    drm: bridge: analogix/dp: add max link rate and lane count limit for
>      RK3288
>    drm: bridge: analogix/dp: try force hpd after plug in lookup failed
>    drm: bridge: analogix/dp: move hpd detect to connector detect function
>    drm: bridge: analogix/dp: add edid modes parse in get_modes method
>
>   .../devicetree/bindings/drm/bridge/analogix_dp.txt |   52 +
>   .../devicetree/bindings/phy/rockchip-dp-phy.txt    |   22 +
>   .../bindings/video/analogix_dp-rockchip.txt        |   91 ++
>   .../devicetree/bindings/video/exynos_dp.txt        |   64 +-
>   arch/arm/boot/dts/exynos5250-arndale.dts           |    2 -
>   arch/arm/boot/dts/exynos5250-smdk5250.dts          |    2 -
>   arch/arm/boot/dts/exynos5250-snow.dts              |    4 +-
>   arch/arm/boot/dts/exynos5250-spring.dts            |    4 +-
>   arch/arm/boot/dts/exynos5420-peach-pit.dts         |    4 +-
>   arch/arm/boot/dts/exynos5420-smdk5420.dts          |    2 -
>   arch/arm/boot/dts/exynos5800-peach-pi.dts          |    4 +-
>   drivers/gpu/drm/bridge/Kconfig                     |    2 +
>   drivers/gpu/drm/bridge/Makefile                    |    1 +
>   drivers/gpu/drm/bridge/analogix/Kconfig            |    4 +
>   drivers/gpu/drm/bridge/analogix/Makefile           |    1 +
>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1372 +++++++++++++++++++
>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  286 ++++
>   drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 1294 ++++++++++++++++++
>   .../analogix/analogix_dp_reg.h}                    |  270 ++--
>   drivers/gpu/drm/exynos/Kconfig                     |    3 +-
>   drivers/gpu/drm/exynos/Makefile                    |    2 +-
>   drivers/gpu/drm/exynos/exynos_dp.c                 |  366 +++++
>   drivers/gpu/drm/exynos/exynos_dp_core.c            | 1427 --------------------
>   drivers/gpu/drm/exynos/exynos_dp_core.h            |  281 ----
>   drivers/gpu/drm/exynos/exynos_dp_reg.c             | 1263 -----------------
>   drivers/gpu/drm/rockchip/Kconfig                   |    9 +
>   drivers/gpu/drm/rockchip/Makefile                  |    1 +
>   drivers/gpu/drm/rockchip/analogix_dp-rockchip.c    |  457 +++++++
>   drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c        |    2 +-
>   drivers/gpu/drm/rockchip/rockchip_drm_drv.h        |    2 +-
>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c        |   32 +-
>   drivers/phy/Kconfig                                |    7 +
>   drivers/phy/Makefile                               |    1 +
>   drivers/phy/phy-rockchip-dp.c                      |  151 +++
>   include/drm/bridge/analogix_dp.h                   |   42 +
>   35 files changed, 4360 insertions(+), 3167 deletions(-)
>   create mode 100644 Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
>   create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
>   create mode 100644 Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
>   create mode 100644 drivers/gpu/drm/bridge/analogix/Kconfig
>   create mode 100644 drivers/gpu/drm/bridge/analogix/Makefile
>   create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>   create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
>   create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
>   rename drivers/gpu/drm/{exynos/exynos_dp_reg.h => bridge/analogix/analogix_dp_reg.h} (62%)
>   create mode 100644 drivers/gpu/drm/exynos/exynos_dp.c
>   delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.c
>   delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h
>   delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.c
>   create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>   create mode 100644 drivers/phy/phy-rockchip-dp.c
>   create mode 100644 include/drm/bridge/analogix_dp.h
>


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1241240

FromJavier Martinez Canillas <javier@osg.samsung.com>
Date2015-10-07 10:50 +0200
Message-ID<qgSAa-86i-11@gated-at.bofh.it>
In reply to#1241166
Hello Yakir,

On 10/07/2015 08:25 AM, Yakir Yang wrote:
> Hi all,
> 
> Friendly ping.....   :)
> 
> 
> Best regards,
> - Yakir
> 
> 

Do you have a tree that I can use to test these patches?

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1241250

FromYakir Yang <ykk@rock-chips.com>
Date2015-10-07 11:10 +0200
Message-ID<qgSTw-gt-9@gated-at.bofh.it>
In reply to#1241240
Hi Javier,

On 10/07/2015 04:46 PM, Javier Martinez Canillas wrote:
> Hello Yakir,
>
> On 10/07/2015 08:25 AM, Yakir Yang wrote:
>> Hi all,
>>
>> Friendly ping.....   :)
>>
>>
>> Best regards,
>> - Yakir
>>
>>
> Do you have a tree that I can use to test these patches?

Wow, thanks a lot, I do have a tree on github 
[https://github.com/yakir-Yang/linux/tree/analogix_dp],
crossing my finger, wish things works......    ;)

Thanks,
- Yakir

>
> Best regards,


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1241278

FromJavier Martinez Canillas <javier@osg.samsung.com>
Date2015-10-07 11:30 +0200
Message-ID<qgTcR-DX-1@gated-at.bofh.it>
In reply to#1241250
Hello Yakir,

On 10/07/2015 11:02 AM, Yakir Yang wrote:
> Hi Javier,
> 
> On 10/07/2015 04:46 PM, Javier Martinez Canillas wrote:
>> Hello Yakir,
>>
>> On 10/07/2015 08:25 AM, Yakir Yang wrote:
>>> Hi all,
>>>
>>> Friendly ping.....   :)
>>>
>>>
>>> Best regards,
>>> - Yakir
>>>
>>>
>> Do you have a tree that I can use to test these patches?
> 
> Wow, thanks a lot, I do have a tree on github [https://github.com/yakir-Yang/linux/tree/analogix_dp],
> crossing my finger, wish things works......    ;)
>

I tried your analogix_dp branch on an Exynos5800 Peach Pi Chromebook
but the machine didn't boot. Unfortunately I need to do some soldering
to have a serial console on this board so don't have a kernel boot log.

I'll let you know if I can get more info about this issue.

Also, there is Kconfig recursive dependency that you may want to fix:

$ make exynos_defconfig
drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_ANALOGIX_DP
drivers/gpu/drm/bridge/analogix/Kconfig:1: symbol DRM_ANALOGIX_DP is selected by DRM_EXYNOS_DP
drivers/gpu/drm/exynos/Kconfig:57: symbol DRM_EXYNOS_DP depends on DRM_EXYNOS_FIMD
drivers/gpu/drm/exynos/Kconfig:19: symbol DRM_EXYNOS_FIMD depends on FB_S3C
drivers/video/fbdev/Kconfig:2023: symbol FB_S3C depends on FB
 
> Thanks,
> - Yakir
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1241397

FromJavier Martinez Canillas <javier@osg.samsung.com>
Date2015-10-07 13:30 +0200
Message-ID<qgV50-3kz-23@gated-at.bofh.it>
In reply to#1241278
Hello Yakir,

On 10/07/2015 01:05 PM, Yakir Yang wrote:
> Hi Javier,
> 
> On 10/07/2015 05:26 PM, Javier Martinez Canillas wrote:
>> Hello Yakir,
>>
>> On 10/07/2015 11:02 AM, Yakir Yang wrote:
>>> Hi Javier,
>>>
>>> On 10/07/2015 04:46 PM, Javier Martinez Canillas wrote:
>>>> Hello Yakir,
>>>>
>>>> On 10/07/2015 08:25 AM, Yakir Yang wrote:
>>>>> Hi all,
>>>>>
>>>>> Friendly ping.....   :)
>>>>>
>>>>>
>>>>> Best regards,
>>>>> - Yakir
>>>>>
>>>>>
>>>> Do you have a tree that I can use to test these patches?
>>> Wow, thanks a lot, I do have a tree on github [https://github.com/yakir-Yang/linux/tree/analogix_dp],
>>> crossing my finger, wish things works......    ;)
>>>
>> I tried your analogix_dp branch on an Exynos5800 Peach Pi Chromebook
>> but the machine didn't boot. Unfortunately I need to do some soldering
>> to have a serial console on this board so don't have a kernel boot log.
>>
>> I'll let you know if I can get more info about this issue.
> 
> Whoops, sorry for the failed, much appreciated for your works.
> 
> Besides, I thought maybe I can find a Peach Pit Chromebook in my side,
> I remember that some of our guys have brought one, but previously I
> thought that mainline kernel wouldn't run on Peach Pit directly.
> 

Great, mainline works correctly on all Exynos based Chromebooks.

> Maybe you can email me the method the run mainline kernel on Peach
> Pit, so I can debug the analogix_dp driver at the same time, that would
> be great.

I wrote a little blog post explaining how to run mainline on these boards:

http://blogs.s-osg.org/install-linux-mainline-kernel-distro-exynos-chromebooks/

That explains the simplest setup though so if you need a different one
(i.e: chain loading a non verified u-boot) or if you have any questions,
feel free to contact me in private and I can help you with the setup.

>> Also, there is Kconfig recursive dependency that you may want to fix:
>>
>> $ make exynos_defconfig
>> drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
>> drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
>> drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
>> drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_ANALOGIX_DP
>> drivers/gpu/drm/bridge/analogix/Kconfig:1: symbol DRM_ANALOGIX_DP is selected by DRM_EXYNOS_DP
>> drivers/gpu/drm/exynos/Kconfig:57: symbol DRM_EXYNOS_DP depends on DRM_EXYNOS_FIMD
>> drivers/gpu/drm/exynos/Kconfig:19: symbol DRM_EXYNOS_FIMD depends on FB_S3C
>> drivers/video/fbdev/Kconfig:2023: symbol FB_S3C depends on FB
>>   
> 
> Yeah, recursive dependency detected, guess I should remove the
> "DRM_KMS_HELPER" from bridge analogix_dp Kconfig file, thanks
> for your remind.
> 
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -1,4 +1,3 @@
>  config DRM_ANALOGIX_DP
>         tristate
>         depends on DRM
> -       select DRM_KMS_HELPER
> 
> 

That fixes the recursive dependency issue indeed. Thanks.

> Thanks,
> - Yakir

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1241905

FromYakir Yang <ykk@rock-chips.com>
Date2015-10-08 02:50 +0200
Message-ID<qh7zb-4q2-11@gated-at.bofh.it>
In reply to#1241397
Hi Javier,

On 10/07/2015 07:25 PM, Javier Martinez Canillas wrote:
> Hello Yakir,
>
> On 10/07/2015 01:05 PM, Yakir Yang wrote:
>> Hi Javier,
>>
>> On 10/07/2015 05:26 PM, Javier Martinez Canillas wrote:
>>> Hello Yakir,
>>>
>>> On 10/07/2015 11:02 AM, Yakir Yang wrote:
>>>> Hi Javier,
>>>>
>>>> On 10/07/2015 04:46 PM, Javier Martinez Canillas wrote:
>>>>> Hello Yakir,
>>>>>
>>>>> On 10/07/2015 08:25 AM, Yakir Yang wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Friendly ping.....   :)
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> - Yakir
>>>>>>
>>>>>>
>>>>> Do you have a tree that I can use to test these patches?
>>>> Wow, thanks a lot, I do have a tree on github [https://github.com/yakir-Yang/linux/tree/analogix_dp],
>>>> crossing my finger, wish things works......    ;)
>>>>
>>> I tried your analogix_dp branch on an Exynos5800 Peach Pi Chromebook
>>> but the machine didn't boot. Unfortunately I need to do some soldering
>>> to have a serial console on this board so don't have a kernel boot log.
>>>
>>> I'll let you know if I can get more info about this issue.
>> Whoops, sorry for the failed, much appreciated for your works.
>>
>> Besides, I thought maybe I can find a Peach Pit Chromebook in my side,
>> I remember that some of our guys have brought one, but previously I
>> thought that mainline kernel wouldn't run on Peach Pit directly.
>>
> Great, mainline works correctly on all Exynos based Chromebooks.
>
>> Maybe you can email me the method the run mainline kernel on Peach
>> Pit, so I can debug the analogix_dp driver at the same time, that would
>> be great.
> I wrote a little blog post explaining how to run mainline on these boards:
>
> http://blogs.s-osg.org/install-linux-mainline-kernel-distro-exynos-chromebooks/
>
> That explains the simplest setup though so if you need a different one
> (i.e: chain loading a non verified u-boot) or if you have any questions,
> feel free to contact me in private and I can help you with the setup.
>

Ah, thanks, gonna to step-by-step.

- Yakir

>>> Also, there is Kconfig recursive dependency that you may want to fix:
>>>
>>> $ make exynos_defconfig
>>> drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
>>> drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
>>> drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER
>>> drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_ANALOGIX_DP
>>> drivers/gpu/drm/bridge/analogix/Kconfig:1: symbol DRM_ANALOGIX_DP is selected by DRM_EXYNOS_DP
>>> drivers/gpu/drm/exynos/Kconfig:57: symbol DRM_EXYNOS_DP depends on DRM_EXYNOS_FIMD
>>> drivers/gpu/drm/exynos/Kconfig:19: symbol DRM_EXYNOS_FIMD depends on FB_S3C
>>> drivers/video/fbdev/Kconfig:2023: symbol FB_S3C depends on FB
>>>    
>> Yeah, recursive dependency detected, guess I should remove the
>> "DRM_KMS_HELPER" from bridge analogix_dp Kconfig file, thanks
>> for your remind.
>>
>> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
>> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
>> @@ -1,4 +1,3 @@
>>   config DRM_ANALOGIX_DP
>>          tristate
>>          depends on DRM
>> -       select DRM_KMS_HELPER
>>
>>
> That fixes the recursive dependency issue indeed. Thanks.
>
>> Thanks,
>> - Yakir
> Best regards,


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1243899

FromYakir Yang <ykk@rock-chips.com>
Date2015-10-10 16:40 +0200
Message-ID<qi3tv-3Hf-5@gated-at.bofh.it>
In reply to#1241905
Hi Javier,

On 10/08/2015 08:40 AM, Yakir Yang wrote:
> On 10/07/2015 07:25 PM, Javier Martinez Canillas wrote:
>> On 10/07/2015 01:05 PM, Yakir Yang wrote:
>>> On 10/07/2015 05:26 PM, Javier Martinez Canillas wrote:
>>>> On 10/07/2015 11:02 AM, Yakir Yang wrote:
>>>>> On 10/07/2015 04:46 PM, Javier Martinez Canillas wrote:
>>>>>> On 10/07/2015 08:25 AM, Yakir Yang wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Friendly ping.....   :)
>>>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>> - Yakir
>>>>>>>
>>>>>>>
>>>>>> Do you have a tree that I can use to test these patches?
>>>>> Wow, thanks a lot, I do have a tree on github 
>>>>> [https://github.com/yakir-Yang/linux/tree/analogix_dp],
>>>>> crossing my finger, wish things works......    ;)
>>>>>
>>>> I tried your analogix_dp branch on an Exynos5800 Peach Pi Chromebook
>>>> but the machine didn't boot. Unfortunately I need to do some soldering
>>>> to have a serial console on this board so don't have a kernel boot 
>>>> log.
>>>>
>>>> I'll let you know if I can get more info about this issue.
>>> Whoops, sorry for the failed, much appreciated for your works.
>>>
>>> Besides, I thought maybe I can find a Peach Pit Chromebook in my side,
>>> I remember that some of our guys have brought one, but previously I
>>> thought that mainline kernel wouldn't run on Peach Pit directly.
>>>
>> Great, mainline works correctly on all Exynos based Chromebooks.
>>
>>> Maybe you can email me the method the run mainline kernel on Peach
>>> Pit, so I can debug the analogix_dp driver at the same time, that would
>>> be great.
>> I wrote a little blog post explaining how to run mainline on these 
>> boards:
>>
>> http://blogs.s-osg.org/install-linux-mainline-kernel-distro-exynos-chromebooks/ 
>>
>>
>> That explains the simplest setup though so if you need a different one
>> (i.e: chain loading a non verified u-boot) or if you have any questions,
>> feel free to contact me in private and I can help you with the setup.
>>
>
> Ah, thanks, gonna to step-by-step.

Thanks for your great material, although I meet some problems in the 
step-by-step
process, and failed at this way to setup mainline kernel environment on 
Exynos chromebooks.

But i do find another way to install mainline kernel to Exynos Chromebook:
1. Install any ChromeOS image into a USB media device (like dd tools)
2. "enable_dev_usb_boot" on Exynos chromebooks which would allowed boot 
from USB.
3. Flash the mainline kernel into the KERNEL-A and KERNEL-B partitions 
on host PC.
4. Insert USB device into Exynos chromebooks, and press CTRL+U, boot 
into USB OS.

And it's better to enable pstore function on mainline kernel, so we can 
analysis the last log when
the mainline kernel crashed. After enable PSTORE_RAM in .config, we 
still need add ramoops node
into file, like:
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -750,6 +750,15 @@
                 iommu = <&sysmmu_gsc3>;
         };

+       ramoops: ramoops {
+               compatible = "ramoops";
+               name = "ramoops";
+               reg = <0x41f00000 0x100000>;
+               record-size = <0x20000>;
+               dump-oops;
+               status = "okay";
+       };
+
         hdmi: hdmi {
                 compatible = "samsung,exynos4212-hdmi";
                 reg = <0x14530000 0x70000>;


Aha, I have tested this series on two Exynos Chromebooks that I 
borrowed(Snow and Peach Pit)
with previously method (actually I believed it's a common method without 
broken the original
ChromeOS image).

And I do find the crash place that make you failed at this series, here 
is the diff changes:
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 5f8fc11..bcbc009 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1169,6 +1169,7 @@ static int analogix_dp_create_bridge(struct 
drm_device *drm_dev,

         dp->bridge = bridge;

+       dp->encoder->bridge = bridge;
         bridge->driver_private = dp;
         bridge->encoder = dp->encoder;
         bridge->funcs = &analogix_dp_bridge_funcs;
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -151,7 +151,7 @@
         samsung,color-depth = <1>;
         samsung,link-rate = <0x06>;
         samsung,lane-count = <2>;
-       hpd-gpio = <&gpx2 6 0>;
+       hpd-gpios = <&gpx2 6 0>;

         ports {
                 port@0 {


Anyway I'm going to send the v6 series, thanks for your good idea.

- Yakir

>
> - Yakir
>
>>>> Also, there is Kconfig recursive dependency that you may want to fix:
>>>>
>>>> $ make exynos_defconfig
>>>> drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
>>>> drivers/video/fbdev/Kconfig:5: symbol FB is selected by 
>>>> DRM_KMS_FB_HELPER
>>>> drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on 
>>>> DRM_KMS_HELPER
>>>> drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by 
>>>> DRM_ANALOGIX_DP
>>>> drivers/gpu/drm/bridge/analogix/Kconfig:1: symbol DRM_ANALOGIX_DP 
>>>> is selected by DRM_EXYNOS_DP
>>>> drivers/gpu/drm/exynos/Kconfig:57: symbol DRM_EXYNOS_DP depends on 
>>>> DRM_EXYNOS_FIMD
>>>> drivers/gpu/drm/exynos/Kconfig:19: symbol DRM_EXYNOS_FIMD depends 
>>>> on FB_S3C
>>>> drivers/video/fbdev/Kconfig:2023: symbol FB_S3C depends on FB
>>> Yeah, recursive dependency detected, guess I should remove the
>>> "DRM_KMS_HELPER" from bridge analogix_dp Kconfig file, thanks
>>> for your remind.
>>>
>>> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
>>> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
>>> @@ -1,4 +1,3 @@
>>>   config DRM_ANALOGIX_DP
>>>          tristate
>>>          depends on DRM
>>> -       select DRM_KMS_HELPER
>>>
>>>
>> That fixes the recursive dependency issue indeed. Thanks.
>>
>>> Thanks,
>>> - Yakir
>> Best regards,
>


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1245493

FromJavier Martinez Canillas <javier@osg.samsung.com>
Date2015-10-13 11:30 +0200
Message-ID<qj44a-2jZ-1@gated-at.bofh.it>
In reply to#1243899
Hello Yakir,

Sorry for the delay but I was on holidays.

On 10/10/2015 04:31 PM, Yakir Yang wrote:
> Hi Javier,

[snip]

>>>
>>>> Maybe you can email me the method the run mainline kernel on Peach
>>>> Pit, so I can debug the analogix_dp driver at the same time, that would
>>>> be great.
>>> I wrote a little blog post explaining how to run mainline on these boards:
>>>
>>> http://blogs.s-osg.org/install-linux-mainline-kernel-distro-exynos-chromebooks/
>>>
>>> That explains the simplest setup though so if you need a different one
>>> (i.e: chain loading a non verified u-boot) or if you have any questions,
>>> feel free to contact me in private and I can help you with the setup.
>>>
>>
>> Ah, thanks, gonna to step-by-step.
> 
> Thanks for your great material, although I meet some problems in the step-by-step
> process, and failed at this way to setup mainline kernel environment on Exynos chromebooks.
> 
> But i do find another way to install mainline kernel to Exynos Chromebook:
> 1. Install any ChromeOS image into a USB media device (like dd tools)
> 2. "enable_dev_usb_boot" on Exynos chromebooks which would allowed boot from USB.
> 3. Flash the mainline kernel into the KERNEL-A and KERNEL-B partitions on host PC.
> 4. Insert USB device into Exynos chromebooks, and press CTRL+U, boot into USB OS.

Yes, as I mentioned in the blog, there are many options. In fact I also boot from
a uSD instead of the eMMC since is easier for me to flash from the host machine
and chain load a non-verified u-boot so I can boot non signed kernels.

But thought that the most common use case would be to install it in the KERN-C and
ROOT-C partitions in the eMMC. Anyways, I'm glad that you got it working.

> 
> And it's better to enable pstore function on mainline kernel, so we can analysis the last log when
> the mainline kernel crashed. After enable PSTORE_RAM in .config, we still need add ramoops node

Interesting, I knew about pstore but I never used it with the Exynos Chromebooks.

> into file, like:
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -750,6 +750,15 @@
>                 iommu = <&sysmmu_gsc3>;
>         };
> 
> +       ramoops: ramoops {
> +               compatible = "ramoops";
> +               name = "ramoops";
> +               reg = <0x41f00000 0x100000>;
> +               record-size = <0x20000>;
> +               dump-oops;
> +               status = "okay";
> +       };
> +

Are you using mainline? There isn't a "ramoops" compatible string documented
in the upstream DT bindings, platform_match() would match by driver name as
a fallback but I don't see code in fs/pstore/ram.c that parses the properties
in your device node. I wonder how this works for you or did I missunderstand?

>         hdmi: hdmi {
>                 compatible = "samsung,exynos4212-hdmi";
>                 reg = <0x14530000 0x70000>;
> 
> 
> Aha, I have tested this series on two Exynos Chromebooks that I borrowed(Snow and Peach Pit)
> with previously method (actually I believed it's a common method without broken the original
> ChromeOS image).
> 
> And I do find the crash place that make you failed at this series, here is the diff changes:
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 5f8fc11..bcbc009 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1169,6 +1169,7 @@ static int analogix_dp_create_bridge(struct drm_device *drm_dev,
> 
>         dp->bridge = bridge;
> 
> +       dp->encoder->bridge = bridge;
>         bridge->driver_private = dp;
>         bridge->encoder = dp->encoder;
>         bridge->funcs = &analogix_dp_bridge_funcs;
> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> @@ -151,7 +151,7 @@
>         samsung,color-depth = <1>;
>         samsung,link-rate = <0x06>;
>         samsung,lane-count = <2>;
> -       hpd-gpio = <&gpx2 6 0>;
> +       hpd-gpios = <&gpx2 6 0>;
> 
>         ports {
>                 port@0 {
> 
> 
> Anyway I'm going to send the v6 series, thanks for your good idea.
>

Great, I'll try to test your latest series on my Peach Pi today.

> - Yakir
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1245735

FromYakir Yang <ykk@rock-chips.com>
Date2015-10-13 16:00 +0200
Message-ID<qj8hr-8pd-1@gated-at.bofh.it>
In reply to#1245493
Hi Javierm

On 10/13/2015 05:21 PM, Javier Martinez Canillas wrote:
> Hello Yakir,
>
> Sorry for the delay but I was on holidays.
>
> On 10/10/2015 04:31 PM, Yakir Yang wrote:
>> Hi Javier,
> [snip]
>
>>>>> Maybe you can email me the method the run mainline kernel on Peach
>>>>> Pit, so I can debug the analogix_dp driver at the same time, that would
>>>>> be great.
>>>> I wrote a little blog post explaining how to run mainline on these boards:
>>>>
>>>> http://blogs.s-osg.org/install-linux-mainline-kernel-distro-exynos-chromebooks/
>>>>
>>>> That explains the simplest setup though so if you need a different one
>>>> (i.e: chain loading a non verified u-boot) or if you have any questions,
>>>> feel free to contact me in private and I can help you with the setup.
>>>>
>>> Ah, thanks, gonna to step-by-step.
>> Thanks for your great material, although I meet some problems in the step-by-step
>> process, and failed at this way to setup mainline kernel environment on Exynos chromebooks.
>>
>> But i do find another way to install mainline kernel to Exynos Chromebook:
>> 1. Install any ChromeOS image into a USB media device (like dd tools)
>> 2. "enable_dev_usb_boot" on Exynos chromebooks which would allowed boot from USB.
>> 3. Flash the mainline kernel into the KERNEL-A and KERNEL-B partitions on host PC.
>> 4. Insert USB device into Exynos chromebooks, and press CTRL+U, boot into USB OS.
> Yes, as I mentioned in the blog, there are many options. In fact I also boot from
> a uSD instead of the eMMC since is easier for me to flash from the host machine
> and chain load a non-verified u-boot so I can boot non signed kernels.
>
> But thought that the most common use case would be to install it in the KERN-C and
> ROOT-C partitions in the eMMC. Anyways, I'm glad that you got it working.

:-P

>> And it's better to enable pstore function on mainline kernel, so we can analysis the last log when
>> the mainline kernel crashed. After enable PSTORE_RAM in .config, we still need add ramoops node
> Interesting, I knew about pstore but I never used it with the Exynos Chromebooks.
>
>> into file, like:
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -750,6 +750,15 @@
>>                  iommu = <&sysmmu_gsc3>;
>>          };
>>
>> +       ramoops: ramoops {
>> +               compatible = "ramoops";
>> +               name = "ramoops";
>> +               reg = <0x41f00000 0x100000>;
>> +               record-size = <0x20000>;
>> +               dump-oops;
>> +               status = "okay";
>> +       };
>> +
> Are you using mainline? There isn't a "ramoops" compatible string documented
> in the upstream DT bindings, platform_match() would match by driver name as
> a fallback but I don't see code in fs/pstore/ram.c that parses the properties
> in your device node. I wonder how this works for you or did I missunderstand?

Aha, I lost some things that I back port the pstore/ram.c from chrome
v3.14 tree which driver would parsed the "ramoops" compatible.

And those "ramoops" device node should be structured by bootloader in
chromeos, so we won't see anything about "ramoops" in DT binding. Due
to I can't upgraded the loader of Peach Pit, so I chose to structure that
device manually. (detailed properties just `cat 
/proc/device-tree/ramoops/*`)

>
>>          hdmi: hdmi {
>>                  compatible = "samsung,exynos4212-hdmi";
>>                  reg = <0x14530000 0x70000>;
>>
>>
>> Aha, I have tested this series on two Exynos Chromebooks that I borrowed(Snow and Peach Pit)
>> with previously method (actually I believed it's a common method without broken the original
>> ChromeOS image).
>>
>> And I do find the crash place that make you failed at this series, here is the diff changes:
>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> index 5f8fc11..bcbc009 100644
>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> @@ -1169,6 +1169,7 @@ static int analogix_dp_create_bridge(struct drm_device *drm_dev,
>>
>>          dp->bridge = bridge;
>>
>> +       dp->encoder->bridge = bridge;
>>          bridge->driver_private = dp;
>>          bridge->encoder = dp->encoder;
>>          bridge->funcs = &analogix_dp_bridge_funcs;
>> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> @@ -151,7 +151,7 @@
>>          samsung,color-depth = <1>;
>>          samsung,link-rate = <0x06>;
>>          samsung,lane-count = <2>;
>> -       hpd-gpio = <&gpx2 6 0>;
>> +       hpd-gpios = <&gpx2 6 0>;
>>
>>          ports {
>>                  port@0 {
>>
>>
>> Anyway I'm going to send the v6 series, thanks for your good idea.
>>
> Great, I'll try to test your latest series on my Peach Pi today.

Thanks

- Yakir
>
>> - Yakir
>>
> Best regards,


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1246394

FromJavier Martinez Canillas <javier@osg.samsung.com>
Date2015-10-14 10:20 +0200
Message-ID<qjprY-15w-15@gated-at.bofh.it>
In reply to#1245735
Hello Yakir,

On 10/13/2015 03:50 PM, Yakir Yang wrote:
> On 10/13/2015 05:21 PM, Javier Martinez Canillas wrote:
> 

[snip]

>>> And it's better to enable pstore function on mainline kernel, so we can analysis the last log when
>>> the mainline kernel crashed. After enable PSTORE_RAM in .config, we still need add ramoops node
>> Interesting, I knew about pstore but I never used it with the Exynos Chromebooks.
>>
>>> into file, like:
>>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>>> @@ -750,6 +750,15 @@
>>>                  iommu = <&sysmmu_gsc3>;
>>>          };
>>>
>>> +       ramoops: ramoops {
>>> +               compatible = "ramoops";
>>> +               name = "ramoops";
>>> +               reg = <0x41f00000 0x100000>;
>>> +               record-size = <0x20000>;
>>> +               dump-oops;
>>> +               status = "okay";
>>> +       };
>>> +
>> Are you using mainline? There isn't a "ramoops" compatible string documented
>> in the upstream DT bindings, platform_match() would match by driver name as
>> a fallback but I don't see code in fs/pstore/ram.c that parses the properties
>> in your device node. I wonder how this works for you or did I missunderstand?
> 
> Aha, I lost some things that I back port the pstore/ram.c from chrome
> v3.14 tree which driver would parsed the "ramoops" compatible.
>

Ah, that explains it then.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web