Re: [PATCH v1 02/12] input: matrix-keymap: func call coding style nit
On Sat, Jun 22, 2013 at 04:18 +0200, Marek Vasut wrote: > > ret = matrix_keypad_map_key(input_dev, rows, cols, row_shift, key); > if (ret) > return ret; > > Now that you return correct error codes from above, you should propagate them > through. Will do, queued for v2. Thank you for reviewing this. virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1 12/12] input: matrix-keypad: add diagnostics in probe()
On Sat, Jun 22, 2013 at 04:28 +0200, Marek Vasut wrote: > > Dear Gerhard Sittig, > > > optionally dump relevant configuration of pins, matrix lines, > > and delay/interval times at the very end of the probe routine > > (development feature, silent by default) > > > > Signed-off-by: Gerhard Sittig > > --- > > drivers/input/keyboard/matrix_keypad.c | 18 ++ > > 1 file changed, 18 insertions(+) > > > > diff --git a/drivers/input/keyboard/matrix_keypad.c > > b/drivers/input/keyboard/matrix_keypad.c index 275b157..69b15720 100644 > > --- a/drivers/input/keyboard/matrix_keypad.c > > +++ b/drivers/input/keyboard/matrix_keypad.c > > @@ -800,6 +800,24 @@ static int matrix_keypad_probe(struct platform_device > > *pdev) device_init_wakeup(&pdev->dev, pdata->wakeup); > > platform_set_drvdata(pdev, keypad); > > > > + dev_dbg(&pdev->dev, "gpios col num[%u] lvl[%s] drv[%s] enc[%s]\n", > > + pdata->num_col_gpios, > > + pdata->col_gpios_active_low ? "low" : "high", > > + pdata->col_gpios_push_pull ? "pp" : "od", > > + pdata->col_gpios_binary_encoded ? "bin" : "1-1"); > > + dev_dbg(&pdev->dev, "gpios row num[%u] lvl[%s]\n", > > + pdata->num_row_gpios, > > + pdata->row_gpios_active_low ? "low" : "high"); > > + dev_dbg(&pdev->dev, "matrix cols[%u] rows[%u] code shift[%u]\n", > > + pdata->num_matrix_cols, > > + pdata->num_matrix_rows, > > + keypad->row_shift); > > + dev_dbg(&pdev->dev, "times scan[%u-%u] bounce[%u] switch[%u]\n", > > + pdata->col_scan_delay_us, > > + pdata->col_scan_delay_us_max, > > + pdata->debounce_ms, > > + pdata->col_switch_delay_ms); > > + > > It's a bit hard to understand this kind of debug output. Besides, we already > have all the DT props in /proc/device-tree where you can check them , do we > really need this patch then ? This output shall reflect not only what was provided to the driver as input, but as well what the driver made of it (that is, some of the values get derived from others, some underwent normalization). The terse format mostly is a consequence of the 80 columns line length limit, and the output being for debugging purposes exclusively. But I understand that one needs to know the driver's internal working before one can read this output. And I felt that this is the only situation where one would enable debugging for the driver. That patch might as well get dropped, I have no strong feelings about it. Actually I put it at the end of the series such that nothing else builds on top of it and that it doesn't change the context of anything else, so that dropping it doesn't matter anyway. virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1 01/12] input: matrix-keypad: update devicetree binding doc
Let me first thank you for reviewing the set and for providing so much feedback! Then let me give a little background: The first part of the series with the doc update doesn't introduce anything new into the driver, it just makes the document catch up with what the driver already does. And the later steps of extending the driver and its getting configured by device tree properties was heavily driven by the desire to keep up strict backwards compatibility. Since breaking a means of input and taking away a UNIX user's keyboard isn't good for your health. :) While I can and do test the setup which the extension is targetting at, I cannot test the other setups due to lack of hardware. So when in doubt, I went with small and unintrusive steps and lots of remarks such that the default behaviour is strictly identical to before the change yet the desired new behaviour becomes available upon request, and all of it is documented. On Fri, Jun 21, 2013 at 15:31 -0600, Stephen Warren wrote: > > On 06/21/2013 12:09 PM, Gerhard Sittig wrote: > > update the device tree binding documentation for the GPIO matrix keypad > > driver: mention the driver's selecting all columns at once, reword the > > delay descriptions, add the missing active low GPIO pin level property > > > diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt > > b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt > > Presumably the changes to this file simply seek to precisely document > the HW that this binding supports, and do not intend to change the > semantics of the binding at all. If that's the case, then they seem fine > to me. > > Have you checked that all users of this binding do assume that the > column GPIOs are output, and rows inputs, rather than the other way > around for example? I suppose if the Linux driver is already implemented > to assume that, then nobody can be successfully using this binding for > HW where that isn't the case, so this change is fine. I understand your concerns very well, since they crossed my mind too when I wrote that update. One way of keeping the driver's details away from the device tree doc might be to create another file under Documentation/input/, discussing all of the driver's operation and the assumed or supported hardware setups there, and reducing the device tree binding doc to just "mention the fact" that something is adjustable and which property to use. This would in addition reduce duplication with other approaches of configuring the driver (there's static platform data as well). Regarding the layering: I'm aware of the one 'GPIO matrix keypad' driver implemented in drivers/input/keyboard/matrix_keypad.c, which uses a pdata structure which can get filled in by means of static platform data provided with code or by parsing the device tree (the preferred method for future extensions). Other drivers may implement their own logic to scan matrices and detect changes, and share the pdata structure since they have to track similar conditions as well. That's the only reason why I had to touch other files than just keypad and keymap. But none of them are device tree aware AFAIK. So yes, from what I can see, the GPIO matrix keypad driver is the only instance which probes the device tree and implements what the binding describes. Which is why I updated the device tree binding's doc to provide motivation why something might need adjustment and what the consequences are of specifying a parameter. But this only applies if the binding is seen in concert with the Linux driver. When the binding gets used elsewhere in the kernel, or when code outside the kernel implements a binding, then the individual driver's details should be kept out of the binding doc. Unless all drivers implement similar logic in just individual ways, because they all need to drive a keypad matrix and thus will face similar problems. Oh well, let's see how others feel or think about it ... Another aspect to keep in mind here is that the current implementation already was layered into "the keypad" which drives the pins and detects presses and may get implemented in several drivers, and "the keymap" which translates key positions to key codes they generate and gets shared among many keypad drivers. I'm not certain about whether the corgi, spitz, palm, tnetv107x and qi_lb60 implementations just share the pdata layout and implement their own logic, or just fillin the pdata from constants provided with the code yet end up creating the same GPIO matrix keypad driver. If they brought their own logic, I could not see how they reference the individual settings, and when they don't inspect new settings then they end up with strictly the former behaviour. If they create the same matrix driver that I extended, and just provide the settings by other means, then they can optionally make use of the new features yet see strictly identical behaviour if they don't adjust what later got introduced.
Re: [PATCH v1 04/12] input: matrix-keypad: push/pull, separate polarity
On Fri, Jun 21, 2013 at 15:34 -0600, Stephen Warren wrote: > > On 06/21/2013 12:09 PM, Gerhard Sittig wrote: > > extend the device tree adjustable hardware configuration: > > - allow for differing polarity of the row and column GPIO pins > > - optionally fully drive column output pins instead of the former > > unconditional open collector emulation approach > > > diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt > > b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt > > > +- row-gpios-activelow: row GPIO pins are active low > > +- col-gpios-activelow: column GPIO pins are active low > > - gpio-activelow: row pins as well as column pins are active low > > + (provided for backward compatibility, and useful > > + for matrix layouts of identical polarity for > > + rows and columns) > > Those should all come from the existing GPIO flags, and may even differ > for each GPIO. > > > +- col-gpios-pushpull: fully drive the column selection pins in either > > + direction (high and low signals), the default > > + behaviour is to actively drive low signals and > > + be passive otherwise (emulates an open collector > > + output driver) > > We don't actually have GPIO flags defined for pushpull-vs-open-collector > etc. Perhaps we should do so. Then, we wouldn't need to invent custom > properties to represent that in this binding. I see your concerns and understand, but chose the above way to just extend the existing implementation in the least intrusive way without changing its nature. See the reply on the first patch for more details on the motivation. Of course I agree that pin properties belong to the GPIO layer and that "application drivers" on top should not worry about that. Were I allowed to break backwards compatibility, then I could have done more shuffling. But lacking the capability to test the affected setups puts more burdon on others, which I wanted to avoid. And then there's the question of whether the "active low" applies to the GPIO pin or to the matrix line (the above property suggests it's the pin, but I'm yet undecided), and whether the subsystems agree on a policy "where to put" the "overall polarity" of such a chain of driver logic and SoC pins and optionally involved inverting drivers and external components which the driver communicates to. The push-pull vs open-drain should never have made it into the keypad driver, but that fact wasn't introduced but did exist. Even if the kernel had no way to setup OD mode of a pin, the bootloader has, and the kernel just needs to setup "values" just like for any other pin regardless of push-pull or open-drain. virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/2] media: i2c: ths8200: Feature enhancement
From: "Lad, Prabhakar" The first patch of the series adds supports for asynchronous subdev registration for ths8200 driver, and the second patch of the series adds OF support the driver. Lad, Prabhakar (2): media: i2c: ths8200: support asynchronous probing media: i2c: ths8200: add OF support .../devicetree/bindings/media/i2c/ths8200.txt | 19 +++ drivers/media/i2c/ths8200.c| 18 +- 2 files changed, 36 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/media/i2c/ths8200.txt -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/2] media: i2c: ths8200: support asynchronous probing
From: "Lad, Prabhakar"
This patch supports both synchronous and asynchronous
ths8200 subdevice probing.
Signed-off-by: Lad, Prabhakar
---
drivers/media/i2c/ths8200.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/ths8200.c b/drivers/media/i2c/ths8200.c
index a24f90c..cc1339a 100644
--- a/drivers/media/i2c/ths8200.c
+++ b/drivers/media/i2c/ths8200.c
@@ -21,6 +21,7 @@
#include
#include
+#include
#include
#include "ths8200_regs.h"
@@ -500,6 +501,7 @@ static int ths8200_probe(struct i2c_client *client,
{
struct ths8200_state *state;
struct v4l2_subdev *sd;
+ int error;
/* Check if the adapter supports the needed features */
if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
@@ -517,6 +519,10 @@ static int ths8200_probe(struct i2c_client *client,
ths8200_core_init(sd);
+ error = v4l2_async_register_subdev(&state->sd);
+ if (error)
+ return error;
+
v4l2_info(sd, "%s found @ 0x%x (%s)\n", client->name,
client->addr << 1, client->adapter->name);
@@ -526,12 +532,13 @@ static int ths8200_probe(struct i2c_client *client,
static int ths8200_remove(struct i2c_client *client)
{
struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct ths8200_state *decoder = to_state(sd);
v4l2_dbg(1, debug, sd, "%s removed @ 0x%x (%s)\n", client->name,
client->addr << 1, client->adapter->name);
ths8200_s_power(sd, false);
-
+ v4l2_async_unregister_subdev(&decoder->sd);
v4l2_device_unregister_subdev(sd);
return 0;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/2] media: i2c: ths8200: add OF support
From: "Lad, Prabhakar"
add OF support for the ths8200 driver.
Signed-off-by: Lad, Prabhakar
---
.../devicetree/bindings/media/i2c/ths8200.txt | 19 +++
drivers/media/i2c/ths8200.c|9 +
2 files changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ths8200.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/ths8200.txt
b/Documentation/devicetree/bindings/media/i2c/ths8200.txt
new file mode 100644
index 000..285f6ae
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ths8200.txt
@@ -0,0 +1,19 @@
+* Texas Instruments THS8200 video encoder
+
+The ths8200 device is a digital to analog converter used in DVD players, video
+recorders, set-top boxes.
+
+Required Properties :
+- compatible : value must be "ti,ths8200"
+
+Example:
+
+ i2c0@1c22000 {
+ ...
+ ...
+ ths8200@5c {
+ compatible = "ti,ths8200";
+ reg = <0x5c>;
+ };
+ ...
+ };
diff --git a/drivers/media/i2c/ths8200.c b/drivers/media/i2c/ths8200.c
index cc1339a..8a29810 100644
--- a/drivers/media/i2c/ths8200.c
+++ b/drivers/media/i2c/ths8200.c
@@ -550,10 +550,19 @@ static struct i2c_device_id ths8200_id[] = {
};
MODULE_DEVICE_TABLE(i2c, ths8200_id);
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id ths8200_of_match[] = {
+ { .compatible = "ti,ths8200", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, ths8200_of_match);
+#endif
+
static struct i2c_driver ths8200_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "ths8200",
+ .of_match_table = of_match_ptr(ths8200_of_match),
},
.probe = ths8200_probe,
.remove = ths8200_remove,
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1 07/12] input: keypad-matrix: introduce polling support
On Fri, Jun 21, 2013 at 15:38 -0600, Stephen Warren wrote: > > On 06/21/2013 12:09 PM, Gerhard Sittig wrote: > > detecting changes in the key press status may not work reliably in > > interrupt driven mode (see the documentation part of the change for > > details) > > > > add support to poll the matrix in software for reliable operation in the > > presence of multi key press events, leave a comment on how sleep and > > wakeup could be made to work appropriately in the polling case > > > diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt > > b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt > > > +The approach to enable all columns at the same time and to determine > > +that a key press status change has occured from row pin level changes > > +only works reliably for single key presses. Multi key presses where the > > +keys share their position on a row line may get deferred or even could > > +go unnoticed, pressing and holding one key will shadow events which > > +another key on the same row would have generated. When reliable > > +detection of key press events is required even in the presence of multi > > +key presses, interrupt mode isn't sufficient any longer, and polling > > +needs to be used. The polling approach to detecting changes in the key > > +press status will periodically activate a single column line and check > > +the signals of the row lines. Polling may also be applicable to setups > > +where the hardware doesn't support the activation of several columns at > > +the same time. > > This feels a bit like encoding a driver implementation detail into the > DT binding. > > Instead, couldn't the driver simply: > > * When no keys are pressed, perhaps after a certain delay/timeout while > scanning, enable "interrupt mode". > > * As soon as an interrupt is seen, switch back to "scanning mode". > > * Once no keys are pressed again, go back to "interrupt mode". > > That way, interrupt mode is only used while no key is pressed, and hence > there's no possibility of shadowing. > > This can all be done without any need for DT binding changes. That's exactly what the GPIO matrix keypad driver did implement and still does by default after it got extended. There is - the "active scan" step which determines the status of individual keys by querying each matrix line individually (in software) and - the "idle" phase where no software is involved but instead a change is detected by changes in the GPIO pins' level while all columns are enabled (wired-OR if you want) The patch set doesn't introduce that behaviour, but merely describes it in more detail. It doesn't even introduce the interrupt discussion into the binding document in a strict sense, but expands on it in the hope for improved usability of the binding after the motivation became more obvious. What this part of the series does is to introduce polling mode as an alternative to the interrupt driven detection of changes, to improve reliability of change detection in the presence of multi key presses. I suggest to have the "meta-discussions" on which documentation belongs where and on where to put the GPIO polarity and on whether backward compatibility needs to be kept or may be broken, in a single spot, to not have several parallel discussions in multiple subthreads. Is the cover letter or the first patch the most appropriate message to respond to with this though in mind? Or don't you mind if several replies for different parts of the patch set discuss similar "background" aspects of the same series? virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1 08/12] input: keypad-matrix: tell GPIO pins from matrix lines
On Fri, Jun 21, 2013 at 15:41 -0600, Stephen Warren wrote: > > On 06/21/2013 12:09 PM, Gerhard Sittig wrote: > > > diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt > > b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt > > > +The driver assumes that all interconnections of the matrix can potentially > > +contain a button, and will submit scan and key code events to the input > > +subsystem. By default the keypad matrix dimenstions are automatically > > +derived from the GPIO pin specifications. Optionally device tree > > +information can override the keypad matrix dimension data, e.g. when not > > +all of the potentially available physical connections are used to create > > +the logical keypad matrix. > > Ignoring the binary encoding in the next patch, why would someone ever > define more row GPIOs that there are rows (or similarly for columns)? > > On its own, I don't think this patch is needed. Well, the keypad's property (remember the layering between keypad and keymap) has already been there, I just made the matrix keypad driver actually use the keymap's DT parse call. Regarding the usefulness of the patch in the absence of binary encodings which only later get introduced: I can't tell how much of a stretch it's going to get perceived as, but I suggested this: A .dtsi may specify the GPIO pins for a keypad attachment (say, the SoC's or module's "potential to drive a matrix", the physical perspective), while boards' .dts files may specify the keymap and its specific layout (the logical matrix description). Not populating logical lines of the matrix will hardly influence the scan time as status changes were detected, and it won't generate key events where interconnects are missing. But it might be desirable to not iterate over empty lines when polling is used to detect changes. Polling was introduced in an earlier part of the series, and allows for reliable detection of multi key press events. So sparse matrices are useful without binary encodings as well. > Now, if you add binary encoding, I can see that you might have say 3 row > GPIOs but only say 6 rows even though there are 8 combinations of row > GPIO values. If that is the situation this patch is intended to cover, > the changes here should be introduced as part of, and only applicable > to, the binary encoding patch instead. I feel that although binary encoding was what I needed in the end, all the other steps taken to get there (except for the last one with the encoding) are of benefit for others as well. virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 4/8] ARM: Add .init_platform() callback to machine descriptor
On Friday 21 of June 2013 16:12:15 Arnd Bergmann wrote: > On Friday 21 June 2013, Tomasz Figa wrote: > > > To me, this new hook is strictly equivalent to init_irq. What do we > > > gain exactly? I didn't think init_irq was going away... > > > > > > I know init_irq is not pretty, and we tend to overload it with other > > > stuff, but I don't really see the point of adding a new callback > > > that > > > has the exact same properties. > > > > Well, it doesn't really give us any functional benefits. > > > > However in my opinion it looks much saner in case of DT-only platforms > > that don't need any specific IRQ initialization, but need to call > > some platform specific initialization routines, after memory > > management, but before anything else is initialized. > > > > This way irqchip_init() doesn't have to be explicitly called in > > platform code. > > > > Anyway, I don't have any strong opinion on this. If it is perfectly > > fine to abuse irqchip_init() for anything that must be done at this > > stage of boot, then I'm fine with this either and will modify the > > board file from further patch from this series to not rely on this > > change any more. > > Your init_platform only has these two calls in it: > > + of_clk_init(NULL); > + samsung_wdt_reset_of_init(); > > Presumably you need of_clk_init() for the watchdog to work. Clock initialization is also required for timekeeping to work, so if we had to defer it, it must happen before (or inside) init_time(). Putting this platform aside, there might be other platforms which require clock initialization before IRQ initialization, e.g. to enable clock of an interrupt controller. > But do you > actually need to initialize the reset logic this early? Why not turn > samsung_wdt_reset_of_init into a standalone driver, or call it from > init_machine? This is debatable. One might want to have reset support working as early as possible to have panic timeout working, but I'm not sure if there is any point of rebooting the machine if the kernel fails so early. Personally I'd prefer this to be a separate driver, in drivers/power/reset/ or wherever appropriate, but I didn't want to change existing behavior too much, which was the reset working already after clock initialization. > I would actually like to call of_clk_init from common code at some point > between init_irq and init_time, although I'm not sure if some platforms > need it to be called before init_irq. Now as I think of it, some platforms might need it earlier, some later, so my init_platform(), which is not flexible at all, would be useless for some of them, that need such things done after init_irq(). I'm going to drop this patch from this series (and simply abuse one of existing callbacks instead), but we should think about a better solution for this issue. Best regards, Tomasz > Arnd > -- > To unsubscribe from this list: send the line "unsubscribe > linux-samsung-soc" in the body of a message to > majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1 10/12] input: keypad_matrix: use usleep_range() for scan delay
On Fri, Jun 21, 2013 at 16:00 -0600, Stephen Warren wrote:
>
> On 06/21/2013 12:09 PM, Gerhard Sittig wrote:
> > querying keyboards isn't a time critical task and does not depend on
> > exact timing in the microseconds order -- the timeouts and delays are
> > arbitrary choices or educated guesses at best anyway
>
> > diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
> > b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
>
> > @@ -93,7 +93,10 @@ Optional Properties:
> > a column line and reading back its row status,
> > such that pin levels can settle after
> > propagating through the matrix and its
> > - associated hardware components
> > + associated hardware components, can be specified
> > + with either one value giving the exact delay, or
> > + with two values giving a delay range (allowing
> > + for reduced timer management overhead)
> > - col-switch-delay-ms: columns switch interval in milliseconds instead
> > of using interrupts to detect key press changes,
> > enables polling mode when specified
> > @@ -146,7 +149,7 @@ Examples:
> > matrix_keypad {
> > compatible = "gpio-matrix-keypad";
> > debounce-delay-ms = <5>;
> > - col-scan-delay-us = <1>;
> > + col-scan-delay-us = <2 10>;
>
> Is it really useful to change the binding this way?
>
> The values in DT presumably represent the minimum delays that the HW
> will tolerate or that are useful. SW is always free to scan more slowly
> than that. As such, if you're simply modifying the driver to allow more
> flexibility in timing, then I don't think you have to modify the DT
> binding to allow for this?
Yes, this puts less burdon on the .dts author. The "problem"
would be to come up (programmatically, without the user's spec)
with an appropriate upper bound.
One might choose "half the col switch delay" when available (in
the polling scenario). Or "three times the lower bound". Or an
arbitrary upper bound in the 100us order. Or actually with the
minimum of all the above. That should keep the absolute minimum
(user specified) in the loop, and scan the keys fast enough, yet
drastically reduce timer management overhead, and hide all of
this from the .dts author.
I will ponder this for a moment ...
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv2 1/3] iio: Add Nuvoton NAU7802 ADC driver
On 06/22/2013 01:55 PM, Jonathan Cameron wrote: > On 06/20/2013 07:57 PM, Alexandre Belloni wrote: >> The Nuvoton NAU7802 ADC is a 24-bit 2-channels I2C ADC, with adjustable >> gain and sampling rates. >> > Sorry, somewhat low on time today so only a quick review. > > 1) Missing userspace ABI documentation. Also, perhaps min_conversions is >a little vague? Not that I have a better idea! I really don't like the name min_conversions either. Isn't this effectively a decimation filter? - Lars ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv2 1/3] iio: Add Nuvoton NAU7802 ADC driver
On 06/20/2013 07:57 PM, Alexandre Belloni wrote:
> The Nuvoton NAU7802 ADC is a 24-bit 2-channels I2C ADC, with adjustable
> gain and sampling rates.
>
Sorry, somewhat low on time today so only a quick review.
1) Missing userspace ABI documentation. Also, perhaps min_conversions is
a little vague? Not that I have a better idea!
2) A lot of i2c calls could do with error handling.
> Signed-off-by: Alexandre Belloni
> Signed-off-by: Maxime Ripard
> ---
> .../bindings/iio/adc/nuvoton-nau7802.txt | 17 +
> drivers/iio/adc/Kconfig| 9 +
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/nau7802.c | 603
> +
> 4 files changed, 630 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
> create mode 100644 drivers/iio/adc/nau7802.c
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
> b/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
> new file mode 100644
> index 000..9bc4218
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/nuvoton-nau7802.txt
> @@ -0,0 +1,17 @@
> +* Nuvoton NAU7802 Analog to Digital Converter (ADC)
> +
> +Required properties:
> + - compatible: Should be "nuvoton,nau7802"
> + - reg: Should contain the ADC I2C address
> +
> +Optional properties:
> + - nuvoton,vldo: Reference voltage in millivolts (integer)
> + - interrupts: IRQ line for the ADC. If not used the driver will use
> +polling.
> +
> +Example:
> +adc2: nau7802@2a {
> + compatible = "nuvoton,nau7802";
> + reg = <0x2a>;
> + nuvoton,vldo = <3000>;
> +};
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index ab0767e6..d7f9ed8 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -133,6 +133,15 @@ config MAX1363
> max11646, max11647) Provides direct access via sysfs and buffered
> data via the iio dev interface.
>
> +config NAU7802
> + tristate "Nuvoton NAU7802 ADC driver"
> + depends on I2C
> + help
> + Say yes here to build support for Nuvoton NAU7802 ADC.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called nau7802.
> +
> config TI_ADC081C
> tristate "Texas Instruments ADC081C021/027"
> depends on I2C
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 0a825be..d426081 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_AT91_ADC) += at91_adc.o
> obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
> obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
> obj-$(CONFIG_MAX1363) += max1363.o
> +obj-$(CONFIG_NAU7802) += nau7802.o
> obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
> obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
> obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
> diff --git a/drivers/iio/adc/nau7802.c b/drivers/iio/adc/nau7802.c
> new file mode 100644
> index 000..e1b6981
> --- /dev/null
> +++ b/drivers/iio/adc/nau7802.c
> @@ -0,0 +1,603 @@
> +/*
> + * Driver for the Nuvoton NAU7802 ADC
> + *
> + * Copyright 2013 Free Electrons
> + *
> + * Licensed under the GPLv2 or later.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define NAU7802_REG_PUCTRL 0x00
> +#define NAU7802_PUCTRL_RR(x) (x << 0)
> +#define NAU7802_PUCTRL_RR_BITNAU7802_PUCTRL_RR(1)
> +#define NAU7802_PUCTRL_PUD(x)(x << 1)
> +#define NAU7802_PUCTRL_PUD_BIT NAU7802_PUCTRL_PUD(1)
> +#define NAU7802_PUCTRL_PUA(x)(x << 2)
> +#define NAU7802_PUCTRL_PUA_BIT NAU7802_PUCTRL_PUA(1)
> +#define NAU7802_PUCTRL_PUR(x)(x << 3)
> +#define NAU7802_PUCTRL_PUR_BIT NAU7802_PUCTRL_PUR(1)
> +#define NAU7802_PUCTRL_CS(x) (x << 4)
> +#define NAU7802_PUCTRL_CS_BITNAU7802_PUCTRL_CS(1)
> +#define NAU7802_PUCTRL_CR(x) (x << 5)
> +#define NAU7802_PUCTRL_CR_BITNAU7802_PUCTRL_CR(1)
> +#define NAU7802_PUCTRL_AVDDS(x) (x << 7)
> +#define NAU7802_PUCTRL_AVDDS_BIT NAU7802_PUCTRL_AVDDS(1)
> +#define NAU7802_REG_CTRL10x01
> +#define NAU7802_CTRL1_VLDO(x)(x << 3)
> +#define NAU7802_CTRL1_GAINS(x) (x)
> +#define NAU7802_CTRL1_GAINS_BITS 0x07
> +#define NAU7802_REG_CTRL20x02
> +#define NAU7802_CTRL2_CHS(x) (x << 7)
> +#define NAU7802_CTRL2_CRS(x) (x << 4)
> +#define NAU7802_SAMP_FREQ_3200x07
> +#define NAU7802_CTRL2_CHS_BITNAU7802_CTRL2_CHS(1)
> +#define NAU7802_REG_ADC_B2 0x12
> +#define NAU7802_REG_ADC_B1 0x13
> +#define NAU7802_REG_ADC_B0 0x14
> +#define NAU7802_REG_ADC_CTRL 0x15
> +
> +#define NAU7802_DEFAULT_CONVERSIONS 6
> +
> +struct nau7802_state {
> + struct i2c_client *client;
> + s32
Re: [PATCH 2/2] regulator: palmas: model SMPS10 as two regulators
On Friday 21 June 2013 07:30 PM, Kishon Vijay Abraham I wrote:
On Friday 21 June 2013 06:55 PM, Laxman Dewangan wrote:
On Thursday 20 June 2013 08:56 PM, Kishon Vijay Abraham I wrote:
Hi,
On Thursday 20 June 2013 08:14 PM, Laxman Dewangan wrote:
Have you added the regulator supply entries?
Are you testing on mainline linux-next?
Not in linux-next :-( Tested only with mainline.
Does inverting the order helps?
I think because you do not have entry of supply in your dt node, it gets
ignored by regulator_dev_lookup() and continue.
I made the entry like (added entry form smps10-out2-supply and smps10-in-supply
in dt node) and then it failed.
/***
+ smps10-out2-supply = <&palmas_smps10_out2_reg>;
+ smps10-in-supply = <&tps65090_dcdc3_reg>;
ldo3-in-supply = <&palmas_smps3_reg>;
@@ -903,6 +905,20 @@
regulator-always-on;
};
+ palmas_smps10_out1_reg: smps10_out1 {
+ regulator-name = "smps10_out1";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ };
+
+ palmas_smps10_out2_reg: smps10_out2 {
+ regulator-name = "smps10_out2";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ };
+
**/
After reversing the sequence, it worked fine.
You mean, changing the order in dt node helped?
The sequence on DT does not matter. We register the regulators in the
sequence it is having enums value for regulator-id in loop. So we need
to revert there.
Yaah, it looks odd that SMPS10-OUT2come before SMPS10-OUT1 in enums
definition.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCHv2 1/3] iio: Add Nuvoton NAU7802 ADC driver
On 06/22/2013 03:07 PM, Alexandre Belloni wrote: > On 22/06/2013 14:02, Lars-Peter Clausen wrote: >> On 06/22/2013 01:55 PM, Jonathan Cameron wrote: >>> On 06/20/2013 07:57 PM, Alexandre Belloni wrote: The Nuvoton NAU7802 ADC is a 24-bit 2-channels I2C ADC, with adjustable gain and sampling rates. >>> Sorry, somewhat low on time today so only a quick review. >>> >>> 1) Missing userspace ABI documentation. Also, perhaps min_conversions is >>>a little vague? Not that I have a better idea! >> I really don't like the name min_conversions either. Isn't this effectively >> a decimation filter? > > Yeah, it could be seen like that but it is only relevant and only > happens when switching between channels. I'm open to any ideas. > I see. Is there anything about this in the datasheet on how many conversions you usually need? Is this really something you need to change at runtime or does moving this to platform data work? - Lars ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1 02/12] input: matrix-keymap: func call coding style nit
Dear Gerhard Sittig, > On Sat, Jun 22, 2013 at 04:18 +0200, Marek Vasut wrote: > > ret = matrix_keypad_map_key(input_dev, rows, cols, row_shift, key); > > if (ret) > > > > return ret; > > > > Now that you return correct error codes from above, you should propagate > > them through. > > Will do, queued for v2. Thank you for reviewing this. Wait a little bit for some more feedback, esp. from the marvell guys ;-) Best regards, Marek Vasut ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v7 5/8] ARM: s3c64xx: Add board file for boot using Device Tree
This patch adds board file that will be used to boot S3C64xx-based boards
using Device Tree.
Signed-off-by: Tomasz Figa
---
arch/arm/mach-s3c64xx/Kconfig | 16 +++
arch/arm/mach-s3c64xx/Makefile | 1 +
arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c | 85 +
3 files changed, 102 insertions(+)
create mode 100644 arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
Changes since v6:
- Dropped the concept of .init_platform() callback and returned back
to the old good abuse of .init_irq().
diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index f78a6a0..fb4258c 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -308,3 +308,19 @@ config MACH_WLF_CRAGG_6410
select SAMSUNG_GPIO_EXTRA128
help
Machine support for the Wolfson Cragganmore S3C6410 variant.
+
+config MACH_S3C64XX_DT
+ bool "Samsung S3C6400/S3C6410 machine using Device Tree"
+ select CLKSRC_OF
+ select CPU_S3C6400
+ select CPU_S3C6410
+ select PINCTRL
+ select PINCTRL_S3C64XX
+ select USE_OF
+ help
+ Machine support for Samsung S3C6400/S3C6410 machines with Device Tree
+ enabled.
+ Select this if a fdt blob is available for your S3C64XX SoC based
+ board.
+ Note: This is under development and not all peripherals can be
+ supported with this machine file.
diff --git a/arch/arm/mach-s3c64xx/Makefile b/arch/arm/mach-s3c64xx/Makefile
index 645a8fe..6faedcf 100644
--- a/arch/arm/mach-s3c64xx/Makefile
+++ b/arch/arm/mach-s3c64xx/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_MACH_SMARTQ7)+= mach-smartq7.o
obj-$(CONFIG_MACH_SMDK6400)+= mach-smdk6400.o
obj-$(CONFIG_MACH_SMDK6410)+= mach-smdk6410.o
obj-$(CONFIG_MACH_WLF_CRAGG_6410) += mach-crag6410.o
mach-crag6410-module.o
+obj-$(CONFIG_MACH_S3C64XX_DT) += mach-s3c64xx-dt.o
diff --git a/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
b/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
new file mode 100644
index 000..3384cb0
--- /dev/null
+++ b/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
@@ -0,0 +1,85 @@
+/*
+ * Samsung's S3C64XX flattened device tree enabled machine
+ *
+ * Copyright (c) 2013 Tomasz Figa
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+#include "common.h"
+
+/*
+ * IO mapping for shared system controller IP.
+ *
+ * FIXME: Make remaining drivers use dynamic mapping.
+ */
+static struct map_desc s3c64xx_dt_iodesc[] __initdata = {
+ {
+ .virtual= (unsigned long)S3C_VA_SYS,
+ .pfn= __phys_to_pfn(S3C64XX_PA_SYSCON),
+ .length = SZ_4K,
+ .type = MT_DEVICE,
+ },
+};
+
+static void __init s3c64xx_dt_map_io(void)
+{
+ debug_ll_io_init();
+ iotable_init(s3c64xx_dt_iodesc, ARRAY_SIZE(s3c64xx_dt_iodesc));
+
+ s3c64xx_init_cpu();
+
+ if (!soc_is_s3c64xx())
+ panic("SoC is not S3C64xx!");
+}
+
+static void __init s3c64xx_dt_init_irq(void)
+{
+ of_clk_init(NULL);
+ samsung_wdt_reset_of_init();
+ irqchip_init();
+};
+
+static void __init s3c64xx_dt_init_machine(void)
+{
+ of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static void s3c64xx_dt_restart(char mode, const char *cmd)
+{
+ if (mode != 's')
+ samsung_wdt_reset();
+
+ /* if all else fails, or mode was for soft, jump to 0 */
+ soft_restart(0);
+}
+
+static char const *s3c64xx_dt_compat[] __initdata = {
+ "samsung,s3c6400",
+ "samsung,s3c6410",
+ NULL
+};
+
+DT_MACHINE_START(S3C6400_DT, "Samsung S3C64xx (Flattened Device Tree)")
+ /* Maintainer: Tomasz Figa */
+ .dt_compat = s3c64xx_dt_compat,
+ .map_io = s3c64xx_dt_map_io,
+ .init_irq = s3c64xx_dt_init_irq,
+ .init_machine = s3c64xx_dt_init_machine,
+ .restart= s3c64xx_dt_restart,
+MACHINE_END
--
1.8.2.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 4/8] ARM: Add .init_platform() callback to machine descriptor
Hi Kukjin, On Friday 21 of June 2013 02:35:20 Tomasz Figa wrote: > Most ARM platforms have parts that should be initialized as early as > possible, which usually means as soon as memory management (kmalloc, > ioremap) starts to work, > > However, currently there is no appropriate callback in machine_desc > struct to use for such initialization and platforms tend to stuff things > up .init_irq() and .init_time() callbacks. > > Since all the DT-based platforms are going towards generic IRQ and time > initialization (using irqchip_init and clocksource_of_init) and current > code assumes that if custom callbacks are not provided in machine_desc > then generic ones should be used, this problem has become a bit more > inconvenient. > > This patch tries to solve this issue by introducing new callback called > .init_platform(), where any custom low level initialization of platform > can be done safely. > > Signed-off-by: Tomasz Figa > --- > arch/arm/include/asm/mach/arch.h | 1 + > arch/arm/kernel/irq.c| 3 +++ > 2 files changed, 4 insertions(+) Please disregard this patch when applying the series (if that happens). Best regards, Tomasz ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Bump version number to 1.4.0
> >> > >> How about if nobody objects, a release is made by the end of the > >> week? > > > > Works for me. > > Great! I didn't see any objections, and the week is basically over. > Are we good for a release today? I get it, thanks. I also have to have time to do it. jdl ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH RFC v3] media: OF: add video sync endpoint property
From: "Lad, Prabhakar"
This patch adds video sync properties as part of endpoint
properties and also support to parse them in the parser.
Signed-off-by: Lad, Prabhakar
Cc: Hans Verkuil
Cc: Laurent Pinchart
Cc: Mauro Carvalho Chehab
Cc: Guennadi Liakhovetski
Cc: Sylwester Nawrocki
Cc: Sakari Ailus
Cc: Grant Likely
Cc: Rob Herring
Cc: Rob Landley
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Cc: Kyungmin Park
---
This patch has 10 warnings for line over 80 characters
for which I think can be ignored.
RFC v2 https://patchwork.kernel.org/patch/2578091/
RFC V1 https://patchwork.kernel.org/patch/2572341/
Changes for v3:
1: Fixed review comments pointed by Laurent and Sylwester.
.../devicetree/bindings/media/video-interfaces.txt |1 +
drivers/media/v4l2-core/v4l2-of.c | 20 ++
include/dt-bindings/media/video-interfaces.h | 17 +++
include/media/v4l2-mediabus.h | 22 +++-
4 files changed, 50 insertions(+), 10 deletions(-)
create mode 100644 include/dt-bindings/media/video-interfaces.h
diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt
b/Documentation/devicetree/bindings/media/video-interfaces.txt
index e022d2d..2081278 100644
--- a/Documentation/devicetree/bindings/media/video-interfaces.txt
+++ b/Documentation/devicetree/bindings/media/video-interfaces.txt
@@ -101,6 +101,7 @@ Optional endpoint properties
array contains only one entry.
- clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous
clock mode.
+- video-sync: property indicating to sync the video on a signal in RGB.
Example
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c
index aa59639..1a54530 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -100,6 +100,26 @@ static void v4l2_of_parse_parallel_bus(const struct
device_node *node,
if (!of_property_read_u32(node, "data-shift", &v))
bus->data_shift = v;
+ if (!of_property_read_u32(node, "video-sync", &v)) {
+ switch (v) {
+ case V4L2_MBUS_VIDEO_SEPARATE_SYNC:
+ flags |= V4L2_MBUS_VIDEO_SEPARATE_SYNC;
+ break;
+ case V4L2_MBUS_VIDEO_COMPOSITE_SYNC:
+ flags |= V4L2_MBUS_VIDEO_COMPOSITE_SYNC;
+ break;
+ case V4L2_MBUS_VIDEO_SYNC_ON_COMPOSITE:
+ flags |= V4L2_MBUS_VIDEO_SYNC_ON_COMPOSITE;
+ break;
+ case V4L2_MBUS_VIDEO_SYNC_ON_GREEN:
+ flags |= V4L2_MBUS_VIDEO_SYNC_ON_GREEN;
+ break;
+ case V4L2_MBUS_VIDEO_SYNC_ON_LUMINANCE:
+ flags |= V4L2_MBUS_VIDEO_SYNC_ON_LUMINANCE;
+ break;
+ }
+ }
+
bus->flags = flags;
}
diff --git a/include/dt-bindings/media/video-interfaces.h
b/include/dt-bindings/media/video-interfaces.h
new file mode 100644
index 000..1a083dd
--- /dev/null
+++ b/include/dt-bindings/media/video-interfaces.h
@@ -0,0 +1,17 @@
+/*
+ * This header provides constants for video interface.
+ *
+ */
+
+#ifndef _DT_BINDINGS_VIDEO_INTERFACES_H
+#define _DT_BINDINGS_VIDEO_INTERFACES_H
+
+#define V4L2_MBUS_VIDEO_SEPARATE_SYNC (1 << 2)
+#define V4L2_MBUS_VIDEO_COMPOSITE_SYNC (1 << 3)
+#define V4L2_MBUS_VIDEO_SYNC_ON_COMPOSITE (1 << 4)
+#define V4L2_MBUS_VIDEO_SYNC_ON_GREEN (1 << 5)
+#define V4L2_MBUS_VIDEO_SYNC_ON_LUMINANCE (1 << 6)
+
+#define V4L2_MBUS_VIDEO_INTERFACES_END 6
+
+#endif
diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
index 83ae07e..a4676dd 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -11,6 +11,8 @@
#ifndef V4L2_MEDIABUS_H
#define V4L2_MEDIABUS_H
+#include
+
#include
/* Parallel flags */
@@ -28,18 +30,18 @@
* V4L2_MBUS_[HV]SYNC* flags should be also used for specifying
* configuration of hardware that uses [HV]REF signals
*/
-#define V4L2_MBUS_HSYNC_ACTIVE_HIGH(1 << 2)
-#define V4L2_MBUS_HSYNC_ACTIVE_LOW (1 << 3)
-#define V4L2_MBUS_VSYNC_ACTIVE_HIGH(1 << 4)
-#define V4L2_MBUS_VSYNC_ACTIVE_LOW (1 << 5)
-#define V4L2_MBUS_PCLK_SAMPLE_RISING (1 << 6)
-#define V4L2_MBUS_PCLK_SAMPLE_FALLING (1 << 7)
-#define V4L2_MBUS_DATA_ACTIVE_HIGH (1 << 8)
-#define V4L2_MBUS_DATA_ACTIVE_LOW (1 << 9)
+#define V4L2_MBUS_HSYNC_ACTIVE_HIGH(1 <<
(V4L2_MBUS_VIDEO_INTERFACES_END + 1))
+#define V4L2_MBUS_HSYNC_ACTIVE_LOW (1 <<
(V4L2_MBUS_VIDEO_INTERFACES_END + 2))
+#define V4L2_MBUS_VSYNC_ACTIVE_HIGH(1 <<
(V4L2_MBUS_VIDEO_INTERFACES_END + 3))
+#define
Re: [PATCH v3 0/5] clk: dt: bindings for mux, divider & gate clocks
Am Freitag, 21. Juni 2013, 08:14:11 schrieb Mike Turquette: > This series introduces binding definitions for common register-mapped > clock multiplexer, divider and gate IP blocks along with the > corresponding setup functions for matching DT data. The bindings are > similar to the struct definitions but please don't hold that against the > binding: the struct definitions closely model the hardware register > layout. > > This version fixes bugs and incorporates support for the hiword-mask > property needed on Hisilicon and Rockchip platforms. > > Tested on OMAP4460 Panda ES. Now it works like a charm :-), so on a rk3066a based board Tested-by: Heiko Stuebner Reviewed-by: Heiko Stuebner > Mike Turquette (5): > clk: divider: replace bitfield width with mask > clk: of: helper for determining number of parent clocks > clk: dt: binding for basic multiplexer clock > clk: dt: binding for basic divider clock > clk: dt: binding for basic gate clock > > .../devicetree/bindings/clock/divider-clock.txt| 90 +++ > .../devicetree/bindings/clock/gate-clock.txt | 36 ++ > .../devicetree/bindings/clock/mux-clock.txt| 79 + > arch/arm/mach-imx/clk-busy.c | 2 +- > drivers/clk/clk-divider.c | 127 > ++--- drivers/clk/clk-gate.c | > 43 +++ > drivers/clk/clk-mux.c | 65 ++- > drivers/clk/clk.c | 6 + > drivers/clk/mxs/clk-div.c | 2 +- > include/linux/clk-private.h| 2 +- > include/linux/clk-provider.h | 12 +- > 11 files changed, 441 insertions(+), 23 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/clock/divider-clock.txt create mode > 100644 Documentation/devicetree/bindings/clock/gate-clock.txt create mode > 100644 Documentation/devicetree/bindings/clock/mux-clock.txt ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 2/2] media: i2c: tvp7002: add OF support
From: "Lad, Prabhakar"
add OF support for the tvp7002 driver.
Signed-off-by: Lad, Prabhakar
Cc: Hans Verkuil
Cc: Laurent Pinchart
Cc: Mauro Carvalho Chehab
Cc: Guennadi Liakhovetski
Cc: Sylwester Nawrocki
Cc: Sakari Ailus
Cc: Grant Likely
Cc: Rob Herring
Cc: Rob Landley
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com
---
Depends on patch https://patchwork.kernel.org/patch/2765851/
.../devicetree/bindings/media/i2c/tvp7002.txt | 43 +
drivers/media/i2c/tvp7002.c| 67 ++--
2 files changed, 103 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp7002.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/tvp7002.txt
b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt
new file mode 100644
index 000..9daebe1
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt
@@ -0,0 +1,43 @@
+* Texas Instruments TV7002 video decoder
+
+The TVP7002 device supports digitizing of video and graphics signal in RGB and
+YPbPr color space.
+
+Required Properties :
+- compatible : Must be "ti,tvp7002"
+
+- hsync-active: HSYNC Polarity configuration for endpoint.
+
+- vsync-active: VSYNC Polarity configuration for endpoint.
+
+- pclk-sample: Clock polarity of the endpoint.
+
+- video-sync: Video sync property of the endpoint.
+
+- ti,tvp7002-fid-polarity: Active-high Field ID polarity of the endpoint.
+
+
+For further reading of port node refer Documentation/devicetree/bindings/media/
+video-interfaces.txt.
+
+Example:
+
+ i2c0@1c22000 {
+ ...
+ ...
+ tvp7002@5c {
+ compatible = "ti,tvp7002";
+ reg = <0x5c>;
+
+ port {
+ tvp7002_1: endpoint {
+ hsync-active = <1>;
+ vsync-active = <1>;
+ pclk-sample = <0>;
+ video-sync =
;
+ ti,tvp7002-fid-polarity;
+ };
+ };
+ };
+ ...
+ };
diff --git a/drivers/media/i2c/tvp7002.c b/drivers/media/i2c/tvp7002.c
index b577548..4896024 100644
--- a/drivers/media/i2c/tvp7002.c
+++ b/drivers/media/i2c/tvp7002.c
@@ -35,6 +35,8 @@
#include
#include
#include
+#include
+
#include "tvp7002_reg.h"
MODULE_DESCRIPTION("TI TVP7002 Video and Graphics Digitizer driver");
@@ -943,6 +945,48 @@ static const struct v4l2_subdev_ops tvp7002_ops = {
.pad = &tvp7002_pad_ops,
};
+static struct tvp7002_config *
+tvp7002_get_pdata(struct i2c_client *client)
+{
+ struct v4l2_of_endpoint bus_cfg;
+ struct tvp7002_config *pdata;
+ struct device_node *endpoint;
+ unsigned int flags;
+
+ if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
+ return client->dev.platform_data;
+
+ endpoint = v4l2_of_get_next_endpoint(client->dev.of_node, NULL);
+ if (!endpoint)
+ return NULL;
+
+ pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ goto done;
+
+ v4l2_of_parse_endpoint(endpoint, &bus_cfg);
+ flags = bus_cfg.bus.parallel.flags;
+
+ if (flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
+ pdata->hs_polarity = 1;
+
+ if (flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH)
+ pdata->vs_polarity = 1;
+
+ if (flags & V4L2_MBUS_PCLK_SAMPLE_RISING)
+ pdata->clk_polarity = 1;
+
+ if (flags & V4L2_MBUS_VIDEO_SYNC_ON_GREEN)
+ pdata->sog_polarity = 1;
+
+ pdata->fid_polarity = of_property_read_bool(endpoint,
+ "ti,tvp7002-fid-polarity");
+
+done:
+ of_node_put(endpoint);
+ return pdata;
+}
+
/*
* tvp7002_probe - Probe a TVP7002 device
* @c: ptr to i2c_client struct
@@ -954,32 +998,32 @@ static const struct v4l2_subdev_ops tvp7002_ops = {
*/
static int tvp7002_probe(struct i2c_client *c, const struct i2c_device_id *id)
{
+ struct tvp7002_config *pdata = tvp7002_get_pdata(c);
struct v4l2_subdev *sd;
struct tvp7002 *device;
struct v4l2_dv_timings timings;
int polarity_a;
int polarity_b;
u8 revision;
-
int error;
+ if (pdata == NULL) {
+ dev_err(&c->dev, "No platform data\n");
+ return -EINVAL;
+ }
+
/* Check if the adapter supports the needed features */
if (!i2c_check_functionality(c->adapter,
I2C_FUNC_SMBUS_READ_BYTE | I2C_FUNC_SMBUS_WRITE_BYTE_DATA))
return -EIO;
- if (!c->dev.platform_data) {
- v4l_err(c, "No platform
Re: [PATCH] Bump version number to 1.4.0
> > Great! I didn't see any objections, and the week is basically over. > Are we good for a release today? Hear Ye! Hear Ye! With a Mandate from the Masses for a tagged release, your wish has finally been granted! $ git tag -v v1.4.0 object 65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf type commit tag v1.4.0 tagger Jon Loeliger 1371924387 -0500 DTC 1.4.0 The Mandate from the Masses release. gpg: Signature made Sat 22 Jun 2013 01:06:41 PM CDT using RSA key ID B0272867 gpg: Good signature from "Jon Loeliger " Enjoy, jdl ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
