lkml.org 
[lkml]   [2014]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v3 5/5] ASoC: dwc: Add documentation for I2S DT
    On Fri, Dec 19, 2014 at 04:18:09PM +0000, Andrew Jackson wrote:

    > Add documentation for Designware I2S hardware block. The block requires
    > two clocks (one for audio sampling, the other for APB) and DMA channels
    > for receive and transmit.

    You should generally include the binding before the code to parse it,
    both because the binding is required in order to tell if the code is
    doing the right thing and also because people will often not even look
    at code with a missing binding.

    > + - clocks : Pairs of phandle and specifier referencing the controller's clocks.
    > + The controller expects two clocks, the clock used for the APB interface and
    > + the clock used as the sampling rate reference clock sample.
    > + - clock-names : "apb_plck" for the clock to the APB interface, "i2sclk" for the sample
    > + rate reference clock.

    This is a name based lookup of clocks but the code doesn't use
    apb_pclk at all; it needs to or the binding needs to say that apb_pclk
    must be the first listed clock (which would not be good).

    > + soc_i2s: i2s@7ff90000 {
    > + compatible = "snps,designware-i2s";
    > + reg = <0x0 0x7ff90000 0x0 0x1000>;
    > + clocks = <&scpi_i2sclk 0>, <&soc_refclk100mhz>;
    > + clock-names = "i2sclk", "apb_pclk";
    > + #sound-dai-cells = <0>;
    > + dmas = <&dma0 5>;
    > + dma-names = "tx";
    > + };

    This omits a lot of configurability that is in platform data and
    replaces it by reading back the parameters from the hardware. If this
    is a viable approach to that configuration you should do this for both
    platform data and device tree rather than only device tree. The point
    with keeping platform data is that it's not good to make the device DT
    only, improving the usability of platform data in a way that happens to
    also make the DT case easier is totally fine. If we can determine how
    the IP is configured from the hardware that's both less work and more
    robust no matter how the device is instantiated.
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2014-12-22 16:01    [W:3.288 / U:0.192 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site