public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Kever Yang <kever.yang@rock-chips.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] pwm: add MACRO to limit some code which only for rk3288
Date: Tue, 12 Jul 2016 10:45:39 +0800	[thread overview]
Message-ID: <578459D3.8060307@rock-chips.com> (raw)
In-Reply-To: <CAPnjgZ0v+acBTg0FCYWrGY+gm-_niRmMjk4mt6QZ8dBeR4E7=g@mail.gmail.com>

Hi Simon,

CC Doug for this topic.

On 07/12/2016 07:54 AM, Simon Glass wrote:
> Hi Kever,
>
> On 11 July 2016 at 00:58, Kever Yang <kever.yang@rock-chips.com> wrote:
>> Hi Simon,
>>
>> On 07/09/2016 10:39 PM, Simon Glass wrote:
>>> Hi Kever,
>>>
>>> On 7 July 2016 at 20:45, Kever Yang <kever.yang@rock-chips.com> wrote:
>>>> The grf setting for rkpwm is only need in rk3288, other SoCs like
>>>> RK3399 which also use rkpwm do not need set the grf, let's add a
>>>> MACRO to make the code only for RK3288.
>>>>
>>>> Change-Id: I167a4e8cf925e840d4bbbcfb1437aaed52b81477
>>> patman will automatically remove these for you.
>> Will use patman for my new patches later, thanks.
>>
>>>> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
>>>> ---
>>>>    drivers/pwm/rk_pwm.c | 8 ++++++++
>>>>    1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/drivers/pwm/rk_pwm.c b/drivers/pwm/rk_pwm.c
>>>> index 2d289a4..e34adf0 100644
>>>> --- a/drivers/pwm/rk_pwm.c
>>>> +++ b/drivers/pwm/rk_pwm.c
>>>> @@ -13,8 +13,10 @@
>>>>    #include <syscon.h>
>>>>    #include <asm/io.h>
>>>>    #include <asm/arch/clock.h>
>>>> +#ifdef CONFIG_ROCKCHIP_RK3288
>>>>    #include <asm/arch/cru_rk3288.h>
>>>>    #include <asm/arch/grf_rk3288.h>
>>>> +#endif
>>>>    #include <asm/arch/pwm.h>
>>>>    #include <power/regulator.h>
>>>>
>>>> @@ -22,7 +24,9 @@ DECLARE_GLOBAL_DATA_PTR;
>>>>
>>>>    struct rk_pwm_priv {
>>>>           struct rk3288_pwm *regs;
>>>> +#ifdef CONFIG_ROCKCHIP_RK3288
>>>>           struct rk3288_grf *grf;
>>>> +#endif
>>>>    };
>>>>
>>>>    static int rk_pwm_set_config(struct udevice *dev, uint channel, uint
>>>> period_ns,
>>>> @@ -65,19 +69,23 @@ static int rk_pwm_ofdata_to_platdata(struct udevice
>>>> *dev)
>>>>           struct regmap *map;
>>>>
>>>>           priv->regs = (struct rk3288_pwm *)dev_get_addr(dev);
>>>> +#ifdef CONFIG_ROCKCHIP_RK3288
>>>>           map = syscon_get_regmap_by_driver_data(ROCKCHIP_SYSCON_GRF);
>>>>           if (IS_ERR(map))
>>>>                   return PTR_ERR(map);
>>>>           priv->grf = regmap_get_range(map, 0);
>>>> +#endif
>>> I'd like to find a better way. Do all chips have a grf? If so then
>>> perhaps we can have a function like grf_enable_pwm() in the core SoC
>>> code and call it here. The #ifdef can be there.
>>>
>>> Or perhaps we should have a general soc.c, with its own struct
>>> containing pointers to grf, sgrf, etc. It can be set up at the start,
>>> and then provide a soc_enable_pwm() function to enable the pwm.
>>>
>>> What do you think?
>> Every Rockchip soc have grf, and maybe sgrf, pmugrf which much like
>> grf. The content in grf are very different for different SoC, it gathers
>> all kinds of system/module control registers .
>> Back to the grf setting for pwm, this control operation is only need in
>> RK3288, not in RK3399 and new SoC further. so I think the '#ifdef' is
>> better to stay in driver file like rk_pwm.c.
>>
>> For these system control registers, I'm sure the dedicate general soc.c is
>> needed, because they are not so common for different module and different
>> Soc. We are not able to have a common framework for them, a general soc.c
>> won't help much except all the system control are gather in one file .
>>
>> I think the GRF setting is part of the module and driver, so we can leave it
>> as it is,
>> and a simple syscon driver is enough for grf like what is kernel do.
> I looked quickly at the Linux pwm driver but I don't see any grf
> access there. How does the grf register get set in Linux? I really
> want to avoid SoC-specific #ifdefs in drivers.
Doug(in cc list) send the patch for this pwm setting, but it seems does 
not accept by upstream,
I think people also don't like this grf access in driver and prefer this 
kind of one time init operation
to be done in bootloader.
patchset 1 implement in arch/arm/mach-rockchip/rockchip.c
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/280064.html
patchset 4 implement in drivers/pwm_rockchip.c
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/280715.html

Hi Doug,
     Do you have any suggestion here?

Thanks,
- Kever
>
>> Thanks,
>> - Kever
>>
>>>>           return 0;
>>>>    }
>>>>
>>>>    static int rk_pwm_probe(struct udevice *dev)
>>>>    {
>>>> +#ifdef CONFIG_ROCKCHIP_RK3288
>>>>           struct rk_pwm_priv *priv = dev_get_priv(dev);
>>>>
>>>>           rk_setreg(&priv->grf->soc_con2, 1 << 0);
>>>> +#endif
>>>>
>>>>           return 0;
>>>>    }
>>>> --
>>>> 1.9.1
>>>>
>>>>
>>> Regards,
>>> Simon
>>>
>>>
>>>
>>
> Regards,
> Simon
>
>
>

  reply	other threads:[~2016-07-12  2:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-08  2:45 [U-Boot] [PATCH] pwm: add MACRO to limit some code which only for rk3288 Kever Yang
2016-07-08  3:44 ` Ziyuan Xu
2016-07-09 14:39 ` Simon Glass
2016-07-11  6:58   ` Kever Yang
2016-07-11 23:54     ` Simon Glass
2016-07-12  2:45       ` Kever Yang [this message]
2016-07-12 13:12         ` Simon Glass
2016-07-29  2:55           ` Kever Yang
2016-07-29  4:46         ` Doug Anderson
2016-09-21 22:01           ` Heiko Stübner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=578459D3.8060307@rock-chips.com \
    --to=kever.yang@rock-chips.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox