Re: [PATCH v3 1/2] drivers/base: permit base components to omit the bind/unbind ops

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

 



On Mon, 10 Feb 2014 13:12:33 +0000
Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote:

> I've NAK'd these patches already - I believe they're based on a
> mis-understanding of how this should be used.  I believe Jean-Francois
> has only looked at the core, rather than looking at the imx-drm example
> it was posted with in an attempt to understand it.
> 
> Omitting the component bind operations is absurd because it makes the
> component code completely pointless, since there is then no way to
> control the sequencing of driver initialisation - something which is
> one of the primary reasons for this code existing in the first place.

I perfectly looked at your example and I use it now in my system.

You did not see what could be done with your component code. For
example, since november, I have not yet the clock probe_defer in the
mainline (http://www.spinics.net/lists/arm-kernel/msg306072.html), so,
there are 3 solutions:

- hope the patch will be some day in the mainline and, today, reboot
  when the system does not start correctly,

- insert a delay in the tda998x and kirkwood probe sequences (delay
  long enough to be sure the si5351 is started, or loop),

- use your component work.

In the last case, it is easy:

- the si5351 driver calls component_add (with empty ops: it has no
  interest in the bind/unbind functions) when it is fully started (i.e.
  registered - that was the subject of my patch),

- in the DRM driver, look for the si5351 as a clock in the DT (drm ->
  encoder -> clock), and add it to the awaited components (CRTCs,
  encoders..),

- in the audio subsystem, look for the si5351 as an external clock in
  the DT (simple-card -> CPU DAI -> clock) and add it to the awaited
  components (CPU and CODEC DAIs - yes, the S/PDIF CODEC should also be
  a component with no bin/unbind ops).

Then, when the si5351 is registered, both master components video and
audio can safely run.


-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel





[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux