Add initial reset controller API documentation. This is mostly indented
to describe the concepts to users of the consumer API, and to tie the
kerneldoc comments we already have into the driver API documentation.
Signed-off-by: Philipp Zabel
---
Documentation/driver-api/index.rst | 1
: Jonathan Corbet
Cc: Lee Jones
Cc: linux-doc@vger.kernel.org
Signed-off-by: Philipp Zabel
---
Documentation/driver-model/devres.txt | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/driver-model/devres.txt
b/Documentation/driver-model/devres.txt
index 30e
o coordinate multiplexer accesses.
> The multiplexer subsystem handles this coordination.
>
> Thanks go out to Lars-Peter Clausen, Jonathan Cameron, Rob Herring,
> Wolfram Sang, Paul Gortmaker, Dan Carpenter, Colin Ian King, Greg
> Kroah-Hartman and last but certainly not least to Philip
> multiplexers, which in that case will be operated in parallel.
>
> Reviewed-by: Jonathan Cameron
> Signed-off-by: Peter Rosin
Reviewed-by: Philipp Zabel
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a mess
On Tue, 2017-04-25 at 16:55 +0200, Peter Rosin wrote:
> On 2017-04-25 16:16, Peter Rosin wrote:
> > On 2017-04-24 16:59, Philipp Zabel wrote:
> >> On Mon, 2017-04-24 at 16:36 +0200, Peter Rosin wrote:
> >> [...]
> >>>> How about an atomic use_count
On Mon, 2017-04-24 at 16:36 +0200, Peter Rosin wrote:
[...]
> > How about an atomic use_count on the mux_control, a bool shared that is
> > only set by the first consumer, and controls whether selecting locks?
>
> That has the drawback that it is hard to restore the mux-control in a safe
> way so
On Mon, 2017-04-24 at 13:37 +0200, Peter Rosin wrote:
> On 2017-04-24 12:52, Philipp Zabel wrote:
> > On Mon, 2017-04-24 at 10:36 +0200, Peter Rosin wrote:
> >> Hi!
> >>
> >> The big change since v13 is that the mux state is now locked with a mutex
> >>
On Mon, 2017-04-24 at 13:37 +0200, Peter Rosin wrote:
[...]
> Ok, so the difference is probably that the rwsem locking primitive
> don't have any lockdep checking hooked up. Because the rwsem was
> definitely held in the same way in v13 as the mutex is now held in
> v14, so there's no fundamental d
On Mon, 2017-04-24 at 10:36 +0200, Peter Rosin wrote:
> Hi!
>
> The big change since v13 is that the mux state is now locked with a mutex
> instead of an rwsem. Other that that, it is mostly restructuring and doc
> changes. There are a few other "real" changes as well, but those changes
> feel kin
On Fri, 2017-04-21 at 16:32 +0200, Peter Rosin wrote:
> On 2017-04-21 16:23, Philipp Zabel wrote:
> > On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
> > [...]
> >> +int mux_chip_register(struct mux_chip *mux_chip)
> >> +{
> >> + int i;
>
On Fri, 2017-04-21 at 16:55 +0200, Peter Rosin wrote:
> On 2017-04-21 16:41, Philipp Zabel wrote:
> > On Fri, 2017-04-21 at 16:32 +0200, Peter Rosin wrote:
> >> On 2017-04-21 16:23, Philipp Zabel wrote:
> >>> On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin
On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
[...]
> +int mux_chip_register(struct mux_chip *mux_chip)
> +{
> + int i;
> + int ret;
> +
> + for (i = 0; i < mux_chip->controllers; ++i) {
> + struct mux_control *mux = &mux_chip->mux[i];
> +
> + if (mux->id
Hi Peter,
On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
[...]
> +int mux_control_select(struct mux_control *mux, int state)
state could be unsigned int for the consumer facing API.
> +{
> + int ret;
And mux_control_select should check that (0 <= state < mux->states).
regards
Philip
On Wed, 2017-04-19 at 13:23 +0200, Peter Rosin wrote:
> On 2017-04-19 13:05, Philipp Zabel wrote:
> > On Wed, 2017-04-19 at 12:41 +0200, Peter Rosin wrote:
> >> On 2017-04-19 11:17, Philipp Zabel wrote:
> >>> On Tue, 2017-04-18 at 15:36 +0200, Peter Rosin wrote:
>
On Wed, 2017-04-19 at 14:00 +0200, Peter Rosin wrote:
[...]
> >> +int mux_control_select(struct mux_control *mux, int state)
> >
> > If we let two of these race, ...
>
> The window for this "race" is positively huge. If there are several
> mux consumers of a single mux controller, it is self-evide
On Wed, 2017-04-19 at 12:41 +0200, Peter Rosin wrote:
> On 2017-04-19 11:17, Philipp Zabel wrote:
> > On Tue, 2017-04-18 at 15:36 +0200, Peter Rosin wrote:
> >> If I got things wrong when I skimmed whatever I came across, and if the
> >> mmio register is the only mux
On Tue, 2017-04-18 at 15:36 +0200, Peter Rosin wrote:
> On 2017-04-18 12:06, Philipp Zabel wrote:
> > On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
> >> Allow specifying that a single multiplexer controller can be used to
> >> control several parallel multiplexer
On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
> Add a new minimalistic subsystem that handles multiplexer controllers.
> When multiplexers are used in various places in the kernel, and the
> same multiplexer controller can be used for several independent things,
> there should be one place
On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
> Allow specifying that a single multiplexer controller can be used to
> control several parallel multiplexers, thus enabling sharing of the
> multiplexer controller by different consumers.
>
> Add a binding for a first mux controller in the fo
Hi Peter,
On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote:
[...]
> diff --git a/include/linux/mux.h b/include/linux/mux.h
> new file mode 100644
> index ..febdde4246df
> --- /dev/null
> +++ b/include/linux/mux.h
[...]
Consider separating mux.h into a consumer header and a driver
On Tue, 2017-03-21 at 16:12 +0100, Neil Armstrong wrote:
> Some display pipelines can only provide non-RBG input pixels to the HDMI TX
> Controller, this patch takes the pixel format from the plat_data if provided.
>
> Signed-off-by: Neil Armstrong
On i.MX6 we could provide RGB/YUV bus formats d
Hi Ricardo,
Am Montag, den 18.07.2016, 15:21 +0200 schrieb Ricardo Ribalda Delgado:
> Hi Philipp
>
> On Mon, Jul 18, 2016 at 3:13 PM, Philipp Zabel wrote:
> > Since the constant expressions are evaluated at compile time, you are
> > not actually removing shifts. T
Hi Ricardo,
Am Montag, den 18.07.2016, 14:42 +0200 schrieb Ricardo Ribalda Delgado:
> Avoid duplicated data shifts when possible.
>
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-
Am Dienstag, den 03.05.2016, 20:41 +0900 schrieb Masahiro Yamada:
> 2016-05-03 19:26 GMT+09:00 Masahiro Yamada :
> > 2016-05-03 19:17 GMT+09:00 Philipp Zabel :
> >> Hi Masahiro,
> >>
> >> Am Sonntag, den 01.05.2016, 19:36 +0900 schrieb Masahiro Yamada
Hi Masahiro,
Am Sonntag, den 01.05.2016, 19:36 +0900 schrieb Masahiro Yamada:
> Add a device managed API for reset_controller_register().
>
> This helps in reducing code in .remove callbacks and sometimes
> dropping .remove callbacks entirely.
>
> Signed-off-by: Masahiro Yamada
Thank you for t
e-König
[...]
Reviewed-by: Philipp Zabel
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
+ void *driver_data);
> +extern void devm_pinctrl_unregister(struct device *dev,
> + struct pinctrl_dev *pctldev);
> +
> extern bool pin_is_valid(struct pinctrl_dev *pctldev, int pin);
> extern void pinctrl_add_gpio_range(struct pinctrl_dev *pctldev,
> struct pinctrl_gpio_range *range);
With those addressed,
Reviewed-by: Philipp Zabel
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
27 matches
Mail list logo
