From: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2] DW SPI: Get clock value from Device Tree
Date: Fri, 27 Oct 2017 13:54:19 +0000 [thread overview]
Message-ID: <1509112458.2551.9.camel@synopsys.com> (raw)
In-Reply-To: <CAD6G_RRgYOuZUu8Kuh5Dv_6vSsMfcb7=rdVOyaeq5AtJvXi1dQ@mail.gmail.com>
On Tue, 2017-10-24 at 15:22 +0530, Jagan Teki wrote:
> On Tue, Oct 24, 2017 at 11:38 AM, Marek Vasut <marex@denx.de> wrote:
> > On 10/23/2017 01:43 PM, Eugeniy Paltsev wrote:
> > > On Thu, 2017-10-19 at 13:20 -0500, Dinh Nguyen wrote:
> > > >
> > > > On 10/19/2017 10:51 AM, Marek Vasut wrote:
> > > > > On 10/19/2017 05:36 PM, Eugeniy Paltsev wrote:
> > > > > > On Tue, 2017-10-17 at 20:32 +0530, Jagan Teki wrote:
> > > > > > > On Tue, Oct 17, 2017 at 8:27 PM, Alexey Brodkin
> > > > > > > <Alexey.Brodkin@synopsys.com> wrote:
> > > > > > > > Hi Jagan,
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Eugeniy Paltsev [mailto:paltsev at synopsys.com]
> > > > > > > > > Sent: Tuesday, October 17, 2017 4:33 PM
> > > > > > > > > To: jagannadh.teki at gmail.com
> > > > > > > > > Cc: u-boot at lists.denx.de; uboot-snps-arc at synopsys.com
> > > > > > > > > Subject: [uboot-snps-arc] Re: [PATCH v2] DW SPI: Get clock value from Device Tree
> > > > > > > > > >
> > > > > > > > > > How hard it is to make others to use clock manager? do you have any list?
> > > > > > > > >
> > > > > > > > > clock_manager.h is an old (and non-generic) way to deal with different clocks.
> > > > > > > > > For example in SOCFPGA_GEN5 and SOCFPGA_ARRIA10 clock_manager.h provides
> > > > > > > > > cm_get_spi_controller_clk_hz function to deal with spi controller clock.
> > > > > > > > >
> > > > > > > > > But today we have another, linux-like alternative: to bind clocks via device tree
> > > > > > > > > and manipulate with clocks via generic functions provided by clk.h
> > > > > > > > >
> > > > > > > > > In this patch I added option to get clock via device tree using standard bindings
> > > > > > > > > and restrict clock_manager.h functions usage only to targets which still use it,
> > > > > > > > > so new targets can simply bind clock via device tree and they do not need to
> > > > > > > > > implement/define something in clock_manager.h
> > > > > > > > >
> > > > > > > > > So we don't need to make others to use clock manager :)
> > > > > > > >
> > > > > > > > Maybe it worth trying the other way around and think about switching SOCFPGA platforms to
> > > > > > > > generic clk framework?
> > > > > > >
> > > > > > > Yes, ie what exactly I thought of, thanks!
> > > > > >
> > > > > > I checked cm_get_spi_controller_clk_hz implementation in SOCFPGA_GEN5 and
> > > > > > SOCFPGA_ARRIA10: we can't simply replace it with "fixed-clock" driver as it
> > > > > > manipulate with real hardware.
> > > > > > The only way to do it is to replace SOCFPGA* clock manager functions by real
> > > > > > clock driver.
> > > > > >
> > > > > > And given I don't have mentioned hardware so I barely can help with
> > > > > > those improvements on SOCFPGA. That said if there're no short-term plans to
> > > > > > switch SOCFPGA to clk framework maybe we'll be OK with my workaround with #ifdefs?
> > > > >
> > > > > Wait for Dinh's reply ...
> > > > >
> > > >
> > > > Honestly, I don't have too much time to work on this right now. So I
> > > > really don't when it can get done. But it'll go on my to-do list.
> > > >
> > > > Dinh
> > >
> > > Yep, thanks for your comments.
> > >
> > > So, Jagan,
> > > given Dinh's reply, could you please apply this patch?
> >
> > I'd really hate it to start seeing soc-specific ifdefs in drivers,
> > that's IMO not acceptable. A __weak override might be a temporary
> > solution I'd be willing to live with though.
>
> I would rather like to see some check on clock manager itself whether
> CONFIG_IS_ENABLED(CLK) is using or not? this can tends not to use
> __weak as well soc #ifdefs in driver.
>
Actually I don't understand what do you mean.
Even if I add any #ifdefs to the clock_manager.h I still need to wrap clock_manager.h
include with #ifdefs as clock_manager.h is defined only for two
targets - SOCFPGA_GEN5 and SOCFPGA_ARRIA10.
#if defined(CONFIG_TARGET_SOCFPGA_GEN5) || defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
#include <asm/arch/clock_manager.h>
#endif
And I think it is better to add this #ifdef in driver than create empty
clock_manager.h file for every new target which uses this driver.
--
Eugeniy Paltsev
next prev parent reply other threads:[~2017-10-27 13:54 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-13 15:18 [U-Boot] [PATCH v2] DW SPI: Get clock value from Device Tree Eugeniy Paltsev
2017-10-16 17:07 ` Jagan Teki
2017-10-17 13:32 ` Eugeniy Paltsev
2017-10-17 14:57 ` Alexey Brodkin
2017-10-17 15:02 ` Jagan Teki
2017-10-19 15:36 ` Eugeniy Paltsev
2017-10-19 15:51 ` Marek Vasut
2017-10-19 18:20 ` Dinh Nguyen
2017-10-23 11:43 ` Eugeniy Paltsev
2017-10-24 6:08 ` Marek Vasut
2017-10-24 9:52 ` Jagan Teki
2017-10-25 6:50 ` Marek Vasut
2017-10-27 13:54 ` Eugeniy Paltsev [this message]
2017-10-28 11:39 ` Marek Vasut
2017-10-30 6:04 ` Jagan Teki
2017-10-30 10:54 ` Marek Vasut
2017-10-30 11:36 ` Jagan Teki
2017-10-30 11:42 ` Marek Vasut
2017-10-31 8:27 ` Jagan Teki
2017-10-31 9:33 ` Marek Vasut
2017-10-17 15:03 ` Marek Vasut
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=1509112458.2551.9.camel@synopsys.com \
--to=eugeniy.paltsev@synopsys.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