RE: 答复: [v7] clk: corenet: Adds the clock binding

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Thanks for your review. I will send next version of patch.

Thanks,
Yuantian


> -----Original Message-----
> From: Wood Scott-B07421
> Sent: 2014年1月10日 星期五 5:19
> To: Tang Yuantian-B29983
> Cc: Mark Rutland; galak@xxxxxxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx;
> linuxppc-dev@xxxxxxxxxxxxxxxx
> Subject: Re: 答复: [v7] clk: corenet: Adds the clock binding
> 
> On Wed, 2014-01-08 at 20:57 -0600, Tang Yuantian-B29983 wrote:
> > Thanks for you review.
> > See my response inline.
> >
> > Thanks,
> > Yuantian
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: 2014年1月9日 星期四 2:44
> > > To: Mark Rutland
> > > Cc: Tang Yuantian-B29983; galak@xxxxxxxxxxxxxxxxxxx;
> > > devicetree@xxxxxxxxxxxxxxx; linuxppc-dev@xxxxxxxxxxxxxxxx
> > > Subject: Re: 答复: [v7] clk: corenet: Adds the clock binding
> > >
> > > On Wed, 2014-01-08 at 09:30 +0000, Mark Rutland wrote:
> > > > On Wed, Jan 08, 2014 at 08:53:56AM +0000, Yuantian Tang wrote:
> > > > >
> > > > > ________________________________________
> > > > > 发件人: Wood Scott-B07421
> > > > > 发送时间: 2014年1月8日 8:21
> > > > > 收件人: Tang Yuantian-B29983
> > > > > 抄送: galak@xxxxxxxxxxxxxxxxxxx; mark.rutland@xxxxxxx;
> > > > > devicetree@xxxxxxxxxxxxxxx; linuxppc-dev@xxxxxxxxxxxxxxxx
> > > > > 主题: Re: [v7] clk: corenet: Adds the clock binding
> > > > >
> > > > > On Wed, Nov 20, 2013 at 05:04:49PM +0800, tang yuantian wrote:
> > > > > > +Recommended properties:
> > > > > > +- ranges: Allows valid translation between child's address
> > > > > > +space
> > > and
> > > > > > +     parent's. Must be present if the device has sub-nodes.
> > > > > > +- #address-cells: Specifies the number of cells used to
> represent
> > > > > > +     physical base addresses.  Must be present if the device
> has
> > > > > > +     sub-nodes and set to 1 if present
> > > > > > +- #size-cells: Specifies the number of cells used to represent
> > > > > > +     the size of an address. Must be present if the device has
> > > > > > +     sub-nodes and set to 1 if present
> > > > >
> > > > > Why are we specifying #address-cells/#size-cells here?
> > > > >
> > > > > A: it has sub-nodes which have REG property, don't we need to
> > > > > specify #address-cells/#size-cells?
> > > >
> > > > If a node has a reg entry, its parent should have #size-cells and
> > > > #address-cells to allow it to be parsed properly.
> > >
> > > Yes, but why do we need to specify in this binding how many cells
> > > there will be, especially since this binding only addresses the
> > > clock provider aspect of the clockgen nodes (e.g. it doesn't
> > > describe the reg)?  Or rather, it's partially describing the
> > > non-clock aspect, and doesn't address the clock aspect at all AFAICT.
> > >
> > First of all, they are not "Required properties", they are optional.
> > If present, we should give them a value of 1.
> 
> Why does it matter, so long as the values translate properly?  It's not
> as if you're defining a special reg format.  It's not that big of a deal,
> but it seems unnecessary.
> 
> > Then, yes, this binding describes clockgen node which is "CLOCK BLOCK".
> 
> Sorry, I missed where "reg" was documented due to the
> required/recommended split.
> 
> > > Where does the actual input clock frequency go?  U-Boot puts it in
> > > the clockgen node itself as clock-frequency, but that isn't
> > > described in the binding.  How does that relate to the sysclk node?
> > > If "fsl,qoriq-sysclk- 1.0" is supposed to indicate that
> > > clock-frequency can be found in the parent node, that isn't
> > > specified by the binding, nor is clock-frequency shown in the example.
> > >
> > clock-frequency is a wired property.
> 
> Do you mean "weird"?
> 
> > It is in clockgen node right now.
> > But it should be placed somewhere in clock nodes.
> 
> If we were doing this from scratch, yes, but there's existing U-Boot code
> that we want to be compatible with.
> 
> > If I describe here, I would be asked why it is related to clockgen node?
> 
> That's not a good reason to leave it undocumented.
> 
> > > What is the difference between "fsl,qoriq-sysclk-1.0" and
> > > "fsl,qoriq- sysclk-2.0"?  How does the concept of a fixed input clock
> change?
> > >
> > Technically, there is no difference between *sysclk-1.0 and *-2.0,
> > just like
> > Clockgen-2.0 and 1.0. Naming like this just to indicate they belong to
> > chassis 2.0 and 1.0 respectively.
> 
> I guess it's OK if it encourages people to consider switching to the
> standard fixed-clock for future chassis.
> 
> So the only thing that really needs to be fixed is the missing clock-
> frequency documentation.
> 
> -Scott
> 

��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux