From: Jean-Francois Moine <moinejf@free.fr>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Thierry Reding <thierry.reding@gmail.com>,
devel@driverdev.osuosl.org, alsa-devel@alsa-project.org,
Takashi Iwai <tiwai@suse.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
dri-devel@lists.freedesktop.org,
Sascha Hauer <kernel@pengutronix.de>,
linux-arm-kernel@lists.infradead.org,
linux-media@vger.kernel.org
Subject: Re: [PATCH v3 1/2] drivers/base: permit base components to omit the bind/unbind ops
Date: Mon, 10 Feb 2014 15:35:51 +0100 [thread overview]
Message-ID: <20140210153551.1309f017@armhf> (raw)
In-Reply-To: <20140210131233.GT26684@n2100.arm.linux.org.uk>
On Mon, 10 Feb 2014 13:12:33 +0000
Russell King - ARM Linux <linux@arm.linux.org.uk> 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/
WARNING: multiple messages have this Message-ID (diff)
From: moinejf@free.fr (Jean-Francois Moine)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 1/2] drivers/base: permit base components to omit the bind/unbind ops
Date: Mon, 10 Feb 2014 15:35:51 +0100 [thread overview]
Message-ID: <20140210153551.1309f017@armhf> (raw)
In-Reply-To: <20140210131233.GT26684@n2100.arm.linux.org.uk>
On Mon, 10 Feb 2014 13:12:33 +0000
Russell King - ARM Linux <linux@arm.linux.org.uk> 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/
next prev parent reply other threads:[~2014-02-10 14:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-07 17:09 [PATCH v3 0/2] *** SUBJECT HERE *** Jean-Francois Moine
2014-02-07 17:09 ` Jean-Francois Moine
2014-02-07 15:55 ` [PATCH v3 1/2] drivers/base: permit base components to omit the bind/unbind ops Jean-Francois Moine
2014-02-07 15:55 ` Jean-Francois Moine
2014-02-07 15:55 ` Jean-Francois Moine
2014-02-10 12:53 ` Thierry Reding
2014-02-10 12:53 ` Thierry Reding
2014-02-10 13:12 ` Russell King - ARM Linux
2014-02-10 13:12 ` Russell King - ARM Linux
2014-02-10 13:12 ` Russell King - ARM Linux
2014-02-10 14:35 ` Jean-Francois Moine [this message]
2014-02-10 14:35 ` Jean-Francois Moine
2014-02-10 15:14 ` Russell King - ARM Linux
2014-02-10 15:14 ` Russell King - ARM Linux
2014-02-10 15:14 ` Russell King - ARM Linux
2014-02-07 16:53 ` [PATCH v3 2/2] drivers/base: declare phandle DT nodes as components Jean-Francois Moine
2014-02-07 16:53 ` Jean-Francois Moine
2014-02-07 16:53 ` Jean-Francois Moine
2014-02-07 17:30 ` [PATCH v3 0/2] *** SUBJECT HERE *** Greg Kroah-Hartman
2014-02-07 17:30 ` Greg Kroah-Hartman
2014-02-07 17:30 ` Greg Kroah-Hartman
2014-02-07 21:43 ` David Lanzendörfer
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=20140210153551.1309f017@armhf \
--to=moinejf@free.fr \
--cc=alsa-devel@alsa-project.org \
--cc=devel@driverdev.osuosl.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-media@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=thierry.reding@gmail.com \
--cc=tiwai@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.