From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755325AbaHGDXQ (ORCPT ); Wed, 6 Aug 2014 23:23:16 -0400 Received: from regular1.263xmail.com ([211.150.99.135]:34230 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754660AbaHGDXO (ORCPT ); Wed, 6 Aug 2014 23:23:14 -0400 X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-ABS-CHECKED: 4 X-KSVirus-check: 0 X-RL-SENDER: caesar.wang@rock-chips.com X-FST-TO: linux-doc@vger.kernel.org X-SENDER-IP: 58.22.7.114 X-LOGIN-NAME: caesar.wang@rock-chips.com X-UNIQUE-TAG: <69e22c99928a5cb4e50b9e46c84bde84> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Message-ID: <53E2F11A.1040109@rock-chips.com> Date: Thu, 07 Aug 2014 11:23:06 +0800 From: caesar User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Doug Anderson CC: Thierry Reding , =?UTF-8?B?SGVpa28gU3TDvGJu?= =?UTF-8?B?ZXI=?= , b.galvani@gmail.com, Rob Herring , Ian Campbell , Randy Dunlap , Kumar Gala , Eddie Cai , Tao Huang , Jianqun Xu , Addy Ke , =?UTF-8?B?6ZmI5riQ6aOe?= , han jiang , "linux-arm-kernel@lists.infradead.org" , linux-pwm , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-doc@vger.kernel.org" Subject: Re: [PATCH v4 2/2] pwm: rockchip: Added to support for RK3288 SoC References: <1406197295-10604-1-git-send-email-caesar.wang@rock-chips.com> <1406197295-10604-3-git-send-email-caesar.wang@rock-chips.com> <53E2D605.2000704@rock-chips.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2014年08月07日 10:16, Doug Anderson 写道: > Caesar, > > On Wed, Aug 6, 2014 at 6:27 PM, caesar wrote: >> Doug, >> >> 在 2014年08月07日 06:46, Doug Anderson 写道: >> >>> Caesar, >>> >>> On Thu, Jul 24, 2014 at 3:21 AM, Caesar Wang >>> wrote: >>>> +static const struct rockchip_pwm_data pwm_data_v1 = { >>>> + .regs.duty = PWM_HRC, >>>> + .regs.period = PWM_LRC, >>>> + .regs.cntr = PWM_CNTR, >>>> + .regs.ctrl = PWM_CTRL, >>>> + .prescaler = PRESCALER, >>>> + .set_enable = rockchip_pwm_set_enable_v1, >>>> +}; >>>> + >>>> +static const struct rockchip_pwm_data pwm_data_v2 = { >>>> + .regs.duty = PWM_LRC, >>>> + .regs.period = PWM_HRC, >>>> + .regs.cntr = PWM_CNTR, >>>> + .regs.ctrl = PWM_CTRL, >>>> + .prescaler = PRESCALER-1, >>>> + .set_enable = rockchip_pwm_set_enable_v2, >>>> +}; >>>> + >>>> +static const struct rockchip_pwm_data pwm_data_vop = { >>>> + .regs.duty = PWM_LRC, >>>> + .regs.period = PWM_HRC, >>>> + .regs.cntr = PWM_CTRL, >>>> + .regs.ctrl = PWM_CNTR, >>> Did you really mean to flip CTRL and CNTR here? If so, that's super >>> confusing and deserves a comment. AKA, I think the above should not >>> be: >>> >>> + .regs.cntr = PWM_CTRL, >>> + .regs.ctrl = PWM_CNTR, >>> >>> ...but should be >>> >>> + .regs.cntr = PWM_CNTR, >>> + .regs.ctrl = PWM_CTRL, >>> >>> If you didn't mean to flip CTRL and CNTR here, then just get rid of >>> pwm_data_vop and refer to pwm_data_v2. In fact, I'd suggest that you >>> totally remove the "rockchip,vop-pwm" since there's nothing different >>> between "rockchip,rk3288-pwm" and "rockchip,vop-pwm". >> >> Sorry,I think it's no problem. the "rockchip,rk3288-pwm" and >> "rockchip,vop-pwm" are seperate PWM controllers. >> They are just different registers address between CNTR and CTRL . > OK, I looked up in the TRM. Right, the CNTR and CTRL are flipped on > the vop. So I think that the only change you need is to add: > > #define PWM_VOP_CTRL 0x00 > #define PWM_VOP_CNTR 0x0c > > ...then use these new #defines for the vop structure. > > > As you have the code written right now it's very confusing. The new > #defines will fix this. > yeah, I think they can be used in the same context. I will fix it in patch v5 if it is really need. > >>> Have you validated Thierry's suggestion to allow you to access your >>> memory range? >> Yes,we have solve it in lcdc driver. >> The Mark Yao have the submission in [0]. >> >> [0]: https://lkml.org/lkml/2014/8/4/20 > Excellent! Then we should be able to land after you fix the above. > > -Doug > > > OK,Thanks!