linux-kernel - Re: [PATCH 2/9] ASoC: cygnus: Update bindings for audio clock changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <492cb202-f4cb-4f5d-5d32-3dee4f1226b5@broadcom.com>
Date:   Wed, 6 Sep 2017 18:45:22 -0700
From:   Lori Hikichi <lori.hikichi@...adcom.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Ray Jui <rjui@...adcom.com>,
        Scott Branden <sbranden@...adcom.com>,
        Jon Mason <jonmason@...adcom.com>,
        bcm-kernel-feedback-list@...adcom.com,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/9] ASoC: cygnus: Update bindings for audio clock changes



On 8/22/2017 9:07 AM, Mark Brown wrote:
> On Wed, Aug 16, 2017 at 12:39:42PM -0700, Lori Hikichi wrote:
>
>> By far the most common usage case for Cygnus is a configuration which
>> uses only the three i2s/tdm ports. In this case each port is assigned
>> a clock.  Each clock has the same capabilities so there would never be
>> a reason change the static mapping.
> The usual reason would be to bring things into sync.
>
>> Now for the case when the "non-audio block" uses one of these clocks.
>> In this situation we will only need one i2s port because this
>> configuration of the chip is not audio intensive.  When the system
>> is designed we know if this non-audio block will be in use, it is not
>> a runtime configurable thing. Again, a static mapping is fine.
> Is this limitation when the other block is in use a physical limitation
> or is it just a case of not seeing the use case.
>
>> At the time it did not seem necessary to make addition driver changes to
>> support a use case that will very likely never arise. As it turns out,
>> we are working on a new version of this audio block.  The clocking
>> configuration for this new version is more complex and I am already in
>> the process of creating clock bindings for all this this. I am hopeful
>> that the driver for this new version will be applicable to Cygnus.
> If the clocking is more complex that seems like even more reason to not
> fix this in the binding, and possibly to do as I think I suggested
> earlier and use the common clock bindings to manage this rather than
> doing something custom and driver specific.
Ok, I will create the necessary clocks to allow this to work.
This will likely impact a couple of the other patches in the series, but
most should be applicable. What would be the best way to have some of the
other patches in this series reviewed?  Should I just drop this series and
resubmit new individual patches for review.