Re: [PATCHv8 06/10] I2C: OMAP: Fix the crash in i2c remove
On Thursday 26 April 2012 11:58 AM, Shubhrajyoti wrote: > On Tuesday 24 April 2012 11:48 PM, Wolfram Sang wrote: >> On Tue, Apr 24, 2012 at 11:44:15PM +0530, Shubhrajyoti wrote: >>> On Monday 23 April 2012 10:19 PM, Wolfram Sang wrote: > [ 154.901153] Exception stack(0xdf9b9fb0 to 0xdf9b9ff8) >> [ 154.907104] 9fa0: beaf1f04 >> 4006be00 000f 000c >> [ 154.915710] 9fc0: 4006c000 8034 ff40 0007 >> 0007b8d7 >> [ 154.916778] 9fe0: beaf1b68 d23c 4005baf0 8010 >> >> [ 154.931335] r6: r5:8010 r4:4005baf0 r3:beaf1f04 >> [ 154.937316] ---[ end trace 1b75b31a2719ed21 ]-- >> >> Cc: >> Signed-off-by: Shubhrajyoti D Is this really the correct solution? I do wonder that every driver using runtime PM should enable the clocks on their own. That should be done by the core, >>> By core you don't mean the i2c core but the pm layer right? >> Yes. >> I'd say; it is not unusual that drivers need to write to registers in remove(). If it is correct, can I get some acks? >>> I did see the crash. >> That was never a doubt. With "correct" I meant "correct solution". >> >>> Will wait for the pm experts to comment. > As far as I know I don’t think that the pm layer doesn't enable the clocks > for the drivers on remove. Maybe Kevin or Rajendra can comment better. typo what i meant was As far as I know the pm layer doesn't enable the clocks for the drivers on remove. Maybe Kevin or Rajendra can comment better. thanks, > > -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 06/10] I2C: OMAP: Fix the crash in i2c remove
On Tuesday 24 April 2012 11:48 PM, Wolfram Sang wrote: > On Tue, Apr 24, 2012 at 11:44:15PM +0530, Shubhrajyoti wrote: >> On Monday 23 April 2012 10:19 PM, Wolfram Sang wrote: [ 154.901153] Exception stack(0xdf9b9fb0 to 0xdf9b9ff8) > [ 154.907104] 9fa0: beaf1f04 > 4006be00 000f 000c > [ 154.915710] 9fc0: 4006c000 8034 ff40 0007 > 0007b8d7 > [ 154.916778] 9fe0: beaf1b68 d23c 4005baf0 8010 > > [ 154.931335] r6: r5:8010 r4:4005baf0 r3:beaf1f04 > [ 154.937316] ---[ end trace 1b75b31a2719ed21 ]-- > > Cc: > Signed-off-by: Shubhrajyoti D >>> Is this really the correct solution? I do wonder that every driver using >>> runtime PM should enable the clocks on their own. That should be done by >>> the core, >> By core you don't mean the i2c core but the pm layer right? > Yes. > >>> I'd say; it is not unusual that drivers need to write to >>> registers in remove(). If it is correct, can I get some acks? >> I did see the crash. > That was never a doubt. With "correct" I meant "correct solution". > >> Will wait for the pm experts to comment. As far as I know I don’t think that the pm layer doesn't enable the clocks for the drivers on remove. Maybe Kevin or Rajendra can comment better. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] i2c-eg20t: add helper function for xfer check
On Mon, Apr 23, 2012 at 1:25 PM, Tomoya MORINAGA wrote: >> >> My checkers found some other issues, for which I will send patches in a >> minute. Please have a look and test. > > OK. > I'll do until this week end and report to you. > These 4 patches posted by you don't affect this driver's logical behavior. So, I only confirmed the driver is compiled without any error/warning. thanks. -- ROHM Co., Ltd. tomoya -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c: mxs: handle spurious interrupt
After an error interrupt setting cmd->err, I see another interrupt that the data engine is empty which clears cmd->err before being processed. So, clear cmd->err at the beginning of a transfer only to handle these consecutive interrupts. Signed-off-by: Wolfram Sang --- drivers/i2c/busses/i2c-mxs.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c index 3d471d5..4c37347 100644 --- a/drivers/i2c/busses/i2c-mxs.c +++ b/drivers/i2c/busses/i2c-mxs.c @@ -227,6 +227,7 @@ static int mxs_i2c_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg, return -EINVAL; init_completion(&i2c->cmd_complete); + i2c->cmd_err = 0; flags = stop ? MXS_I2C_CTRL0_POST_SEND_STOP : 0; @@ -299,8 +300,6 @@ static irqreturn_t mxs_i2c_isr(int this_irq, void *dev_id) MXS_I2C_CTRL1_SLAVE_STOP_IRQ | MXS_I2C_CTRL1_SLAVE_IRQ)) /* MXS_I2C_CTRL1_OVERSIZE_XFER_TERM_IRQ is only for slaves */ i2c->cmd_err = -EIO; - else - i2c->cmd_err = 0; is_last_cmd = (readl(i2c->regs + MXS_I2C_QUEUESTAT) & MXS_I2C_QUEUESTAT_WRITE_QUEUE_CNT_MASK) == 0; -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c: muxes: rename first set of drivers to a standard pattern
Apply a naming pattern like in the rest of the subsystem to a first set
of mux drivers. Those drivers are the low-hanging fruit; we want to pick
them to motivate upcoming drivers to follow the new pattern. The missing
GPIO driver will be converted in a later patch.
Signed-off-by: Wolfram Sang
Acked-by: Guenter Roeck (pca9541)
Cc: Michael Lawnick
Cc: Jean Delvare
---
drivers/i2c/muxes/Kconfig |4 ++--
drivers/i2c/muxes/Makefile |4 ++--
drivers/i2c/muxes/{pca9541.c => i2c-mux-pca9541.c} |0
drivers/i2c/muxes/{pca954x.c => i2c-mux-pca954x.c} |0
4 files changed, 4 insertions(+), 4 deletions(-)
rename drivers/i2c/muxes/{pca9541.c => i2c-mux-pca9541.c} (100%)
rename drivers/i2c/muxes/{pca954x.c => i2c-mux-pca954x.c} (100%)
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 90b7a01..e14a420 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -25,7 +25,7 @@ config I2C_MUX_PCA9541
I2C Master Selector.
This driver can also be built as a module. If so, the module
- will be called pca9541.
+ will be called i2c-mux-pca9541.
config I2C_MUX_PCA954x
tristate "Philips PCA954x I2C Mux/switches"
@@ -35,6 +35,6 @@ config I2C_MUX_PCA954x
I2C mux/switch devices.
This driver can also be built as a module. If so, the module
- will be called pca954x.
+ will be called i2c-mux-pca954x.
endmenu
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index 4640436..0868335 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -2,7 +2,7 @@
# Makefile for multiplexer I2C chip drivers.
obj-$(CONFIG_I2C_MUX_GPIO) += gpio-i2cmux.o
-obj-$(CONFIG_I2C_MUX_PCA9541) += pca9541.o
-obj-$(CONFIG_I2C_MUX_PCA954x) += pca954x.o
+obj-$(CONFIG_I2C_MUX_PCA9541) += i2c-mux-pca9541.o
+obj-$(CONFIG_I2C_MUX_PCA954x) += i2c-mux-pca954x.o
ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
diff --git a/drivers/i2c/muxes/pca9541.c b/drivers/i2c/muxes/i2c-mux-pca9541.c
similarity index 100%
rename from drivers/i2c/muxes/pca9541.c
rename to drivers/i2c/muxes/i2c-mux-pca9541.c
diff --git a/drivers/i2c/muxes/pca954x.c b/drivers/i2c/muxes/i2c-mux-pca954x.c
similarity index 100%
rename from drivers/i2c/muxes/pca954x.c
rename to drivers/i2c/muxes/i2c-mux-pca954x.c
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 3/5] i2c: Add of_i2c_get_adapter() function
* Stephen Warren wrote: > On 04/25/2012 03:45 AM, Thierry Reding wrote: > > This function resolves an OF device node to an I2C adapter registered > > with the I2C core. > > I think this is doing the same thing as a patch I posted recently: > http://www.spinics.net/lists/linux-i2c/msg07808.html I wasn't aware of that patch. > What's the advantage of one way over the other? Both are fine I think. Your version is shorter but mine may be a little faster since it doesn't iterate over all devices on the bus. Since the lookup doesn't happen very frequently this isn't much of an issue. Thierry pgp2HLoqZfdQI.pgp Description: PGP signature
Re: [RFC v2 3/5] i2c: Add of_i2c_get_adapter() function
On 04/25/2012 03:45 AM, Thierry Reding wrote: > This function resolves an OF device node to an I2C adapter registered > with the I2C core. I think this is doing the same thing as a patch I posted recently: http://www.spinics.net/lists/linux-i2c/msg07808.html What's the advantage of one way over the other? -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] I2C: xiic: Add OF binding support
Signed-off-by: Lars-Peter Clausen
---
Documentation/devicetree/bindings/i2c/xiic.txt | 22 ++
drivers/i2c/busses/i2c-xiic.c | 23 ++-
2 files changed, 40 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/i2c/xiic.txt
diff --git a/Documentation/devicetree/bindings/i2c/xiic.txt
b/Documentation/devicetree/bindings/i2c/xiic.txt
new file mode 100644
index 000..ceabbe9
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/xiic.txt
@@ -0,0 +1,22 @@
+Xilinx IIC controller:
+
+Required properties:
+- compatible : Must be "xlnx,xps-iic-2.00.a"
+- reg : IIC register location and length
+- interrupts : IIC controller unterrupt
+- #address-cells = <1>
+- #size-cells = <0>
+
+Optional properties:
+- Child nodes conforming to i2c bus binding
+
+Example:
+
+ axi_iic_0: i2c@4080 {
+ compatible = "xlnx,xps-iic-2.00.a";
+ interrupts = < 1 2 >;
+ reg = < 0x4080 0x1 >;
+
+ #size-cells = <0>;
+ #address-cells = <1>;
+ };
diff --git a/drivers/i2c/busses/i2c-xiic.c b/drivers/i2c/busses/i2c-xiic.c
index 2bded76..641d0e5 100644
--- a/drivers/i2c/busses/i2c-xiic.c
+++ b/drivers/i2c/busses/i2c-xiic.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#define DRIVER_NAME "xiic-i2c"
@@ -705,8 +706,6 @@ static int __devinit xiic_i2c_probe(struct platform_device
*pdev)
goto resource_missing;
pdata = (struct xiic_i2c_platform_data *) pdev->dev.platform_data;
- if (!pdata)
- return -EINVAL;
i2c = kzalloc(sizeof(*i2c), GFP_KERNEL);
if (!i2c)
@@ -730,6 +729,7 @@ static int __devinit xiic_i2c_probe(struct platform_device
*pdev)
i2c->adap = xiic_adapter;
i2c_set_adapdata(&i2c->adap, i2c);
i2c->adap.dev.parent = &pdev->dev;
+ i2c->adap.dev.of_node = pdev->dev.of_node;
xiic_reinit(i2c);
@@ -748,9 +748,13 @@ static int __devinit xiic_i2c_probe(struct platform_device
*pdev)
goto add_adapter_failed;
}
- /* add in known devices to the bus */
- for (i = 0; i < pdata->num_devices; i++)
- i2c_new_device(&i2c->adap, pdata->devices + i);
+ if (pdata) {
+ /* add in known devices to the bus */
+ for (i = 0; i < pdata->num_devices; i++)
+ i2c_new_device(&i2c->adap, pdata->devices + i);
+ }
+
+ of_i2c_register_devices(&i2c->adap);
return 0;
@@ -795,12 +799,21 @@ static int __devexit xiic_i2c_remove(struct
platform_device* pdev)
return 0;
}
+#if defined(CONFIG_OF)
+static const struct of_device_id xiic_of_match[] __devinitconst = {
+ { .compatible = "xlnx,xps-iic-2.00.a", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, xiic_of_match);
+#endif
+
static struct platform_driver xiic_i2c_driver = {
.probe = xiic_i2c_probe,
.remove = __devexit_p(xiic_i2c_remove),
.driver = {
.owner = THIS_MODULE,
.name = DRIVER_NAME,
+ .of_match_table = of_match_ptr(xiic_of_match),
},
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 0/5] Add NVIDIA Tegra DRM support
* Thierry Reding wrote: > This series adds a basic DRM driver for NVIDIA Tegra 2 processors. It > currently only supports the RGB output and I've successfully tested it > against the fbcon kernel module and the xf86-video-modesetting driver. > The code uses the Tegra's IOMMU/GART to remap non-contiguous memory. > This means that currently video memory is limited to 32 MB, the size of > the GART aperture. > > Changes in v2: > - split into several smaller source files > - represent individual devices in DT > - add drivers for individual devices > - EDID probing support via "ddc" property > - EDID support in DT using binary blobs > - basic (non-working) HDMI support > - support for carveout memory in DT > > A lot of the above are really just stub implementations. Most notably > HDMI support is pretty much a copy of what NVIDIA has in their > downstream kernels, though I wasn't able to make it work except for the > EDID probing (I probably missed some pieces). Carveout memory also isn't > used right now. > > Still this should now be in a state where other people (like Jon and > Terje from NVIDIA) and Lucas can start contributing. This series is > based on next-20120424. I also just finished uploading this series to gitorious: https://gitorious.org/thierryreding/linux/commits/tegra/drm/next Thierry pgprdPQthjn8Z.pgp Description: PGP signature
Re: [PATCH 1/2] i2c-s3c2410: Rework device type handling
On 24.04.2012 16:44, Wolfram Sang wrote:
> On Tue, Apr 24, 2012 at 10:40:49AM +0200, Karol Lewandowski wrote:
>> On 23.04.2012 20:20, Wolfram Sang wrote:
+ if (pdev->dev.of_node) {
+ const struct of_device_id *match;
+ match = of_match_node(&s3c24xx_i2c_match, pdev->dev.of_node);
>>>
>>> I'd appreciate a comment explaining why match can't be NULL here (as to
>>> my understanding, it can't). Or just check for it, but this way it looks
>>> a bit fishy and people (hopefully ;)) will ask about it.
>>
>>
>> My understanding is that it can't be null for exactly same reason why
>> platform_get_device_id(pdev) can't be null either (see below).
>>
>> I.e. prerequisite for this code to be run at all (as it's called from
>> driver's .probe()) is to be already matched against very same match
>> table.
>
> Yes, I agree. Yet, this is not obvious and people might try to fix it
> (especially since programs like smatch report it as potentially
> dangerous). Ah, whatever, I could simply apply the fix then :) OK.
Great! I hope it won't cause any problems. :)
Regards,
--
Karol Lewandowski | Samsung Poland R&D Center | Linux/Platform
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 2/5] tps6586x: Add device tree support
* Mark Brown wrote:
> On Wed, Apr 25, 2012 at 12:41:47PM +0200, Thierry Reding wrote:
>
> > After taking a closer look I don't think Rhyland's patch is very useful for
> > this driver. I need to lookup the platform ID by regulator name anyway so
> > using the new code is actually more work and requires a second table that
> > lists the regulator names only.
>
> Why do you need the plaform ID, and if it is needed could we work out a
> way to make the generic code do that lookup for you (since presumably
> other drivers will have the same requirement)? If you can't use the
> generic code it seems like the fix is to enhance the generic code and
> I'd expect that something not requiring the platform ID would just be
> able to igore that information if the generic code could look it up.
Basically the platform ID is used by the regulator driver to differentiate
between the different types of regulators. I could imagine a more advanced
setup to do the matching, along the lines of OF device matching and platform
device matching, where an entry in the table has both a name and an
associated "driver data" field.
For instance we could have a new structure:
struct regulator_lookup_data {
const char *name;
unsigned long driver_data;
struct regulator_init_data *init_data;
struct device_node *of_node;
};
static struct regulator_lookup_data tps6586x_lookup[] = {
{ .name = "sm0", .driver_data = TPS6586X_ID_SM_0 },
{ .name = "sm1", .driver_data = TPS6586X_ID_SM_1 },
...
};
And pass that into of_find_regulator_init_data_from_device():
of_find_regulator_init_data_from_device(&client->dev, regulators,
tps6586x_lookup,
ARRAY_SIZE(tps6586x_lookup));
Upon return, the tps6586x_lookup table will have the init_data and of_node
fields filled with the data parsed from the DT. Then we can simply iterate
over all entries and add the corresponding regulators.
This is somewhat ugly because of_find_regulator_init_data_from_device() would
modify the same data structure for potentially different devices. This should
be okay because the driver core takes care of serializing device probing
(unless I am mistaken). Alternatively we could make the function return a
copy of the regulator_lookup_data structure with the additional fields filled
in.
Thierry
pgpJM1xTpGacK.pgp
Description: PGP signature
Re: [PATCH V2] i2c: Add generic I2C multiplexer using pinctrl API
On Tue, Apr 24, 2012 at 11:02 PM, Stephen Warren wrote: > On 04/24/2012 02:09 PM, Wolfram Sang wrote: >> >> From what I know, compatible-properties should not be linux-specific >> since devicetrees are OS independent. pinctrl-i2cmux sounds >> linux-specific to me. >> >> So, is such a binding acceptable meanwhile? > > To my mind, "pinctrl" has two meanings: (1) is the Linux internal API > (2) is the pinctrl bindings in > Documentation/devicetree/bindings/pinctrl, which were admittedly > developed strongly based on Linux's pinctrl API needs, but I believe > should be completely agnostic to the pinctrl API, SW, OS, etc., and > hence can be considered a pure representation of hardware. > > As such, the "pinctrl" in "pinctrl-i2cmux" above refers to (2) above, > and can be considered a pure HW/binding term. I second Stephens statement. Now every OS in the world must start to think about these things as pin controllers. But tt's not like there is competing terminology anyway, so let's define this before we get into committee meetings... Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 2/5] tps6586x: Add device tree support
On Wed, Apr 25, 2012 at 12:41:47PM +0200, Thierry Reding wrote: > After taking a closer look I don't think Rhyland's patch is very useful for > this driver. I need to lookup the platform ID by regulator name anyway so > using the new code is actually more work and requires a second table that > lists the regulator names only. Why do you need the plaform ID, and if it is needed could we work out a way to make the generic code do that lookup for you (since presumably other drivers will have the same requirement)? If you can't use the generic code it seems like the fix is to enhance the generic code and I'd expect that something not requiring the platform ID would just be able to igore that information if the generic code could look it up. signature.asc Description: Digital signature
Re: [RFC v2 2/5] tps6586x: Add device tree support
* Thierry Reding wrote: > * Mark Brown wrote: > > On Wed, Apr 25, 2012 at 11:44:59AM +0200, Thierry Reding wrote: > > > This commit adds device tree support for the TPS6586x regulator. > > > > > > Signed-off-by: Thierry Reding > > > > This looks basically good from a quick scan through but the pattern of > > looking up regulator nodes by name is very common so should be factored > > out - I made a similar comment in response to a recent patch from > > Rhyland Klein and earlier today he posted a patch "regulator: add > > generic of node parsing for regulators" which does just that. Can you > > please redo this on top of his code? I'll probably apply it later > > today, though I didn't properly read the code yet. > > I'll take a look. After taking a closer look I don't think Rhyland's patch is very useful for this driver. I need to lookup the platform ID by regulator name anyway so using the new code is actually more work and requires a second table that lists the regulator names only. Thierry pgpDC13984qsJ.pgp Description: PGP signature
Re: [RFC v2 2/5] tps6586x: Add device tree support
* Mark Brown wrote: > On Wed, Apr 25, 2012 at 11:44:59AM +0200, Thierry Reding wrote: > > This commit adds device tree support for the TPS6586x regulator. > > > > Signed-off-by: Thierry Reding > > This looks basically good from a quick scan through but the pattern of > looking up regulator nodes by name is very common so should be factored > out - I made a similar comment in response to a recent patch from > Rhyland Klein and earlier today he posted a patch "regulator: add > generic of node parsing for regulators" which does just that. Can you > please redo this on top of his code? I'll probably apply it later > today, though I didn't properly read the code yet. I'll take a look. > I guess it should be possible to apply this patch independantly of the > rest of the series? It shouldn't break bisection if it's missing as > it's a new driver that's being added as the consumer. Yes, it can be applied independently. Thierry pgpnk52sD8rm7.pgp Description: PGP signature
Re: [RFC v2 2/5] tps6586x: Add device tree support
On Wed, Apr 25, 2012 at 11:44:59AM +0200, Thierry Reding wrote: > This commit adds device tree support for the TPS6586x regulator. > > Signed-off-by: Thierry Reding This looks basically good from a quick scan through but the pattern of looking up regulator nodes by name is very common so should be factored out - I made a similar comment in response to a recent patch from Rhyland Klein and earlier today he posted a patch "regulator: add generic of node parsing for regulators" which does just that. Can you please redo this on top of his code? I'll probably apply it later today, though I didn't properly read the code yet. I guess it should be possible to apply this patch independantly of the rest of the series? It shouldn't break bisection if it's missing as it's a new driver that's being added as the consumer. signature.asc Description: Digital signature
[RFC v2 0/5] Add NVIDIA Tegra DRM support
This series adds a basic DRM driver for NVIDIA Tegra 2 processors. It currently only supports the RGB output and I've successfully tested it against the fbcon kernel module and the xf86-video-modesetting driver. The code uses the Tegra's IOMMU/GART to remap non-contiguous memory. This means that currently video memory is limited to 32 MB, the size of the GART aperture. Changes in v2: - split into several smaller source files - represent individual devices in DT - add drivers for individual devices - EDID probing support via "ddc" property - EDID support in DT using binary blobs - basic (non-working) HDMI support - support for carveout memory in DT A lot of the above are really just stub implementations. Most notably HDMI support is pretty much a copy of what NVIDIA has in their downstream kernels, though I wasn't able to make it work except for the EDID probing (I probably missed some pieces). Carveout memory also isn't used right now. Still this should now be in a state where other people (like Jon and Terje from NVIDIA) and Lucas can start contributing. This series is based on next-20120424. Thierry Robert Morell (1): drm: fixed: Add dfixed_frac Thierry Reding (4): iommu: Include linux/types.h tps6586x: Add device tree support i2c: Add of_i2c_get_adapter() function drm: Add NVIDIA Tegra support .../devicetree/bindings/gpu/drm/tegra.txt | 125 +++ .../devicetree/bindings/regulator/tps6586x.txt | 97 ++ arch/arm/mach-tegra/board-dt-tegra20.c | 14 + arch/arm/mach-tegra/include/mach/iomap.h |6 + arch/arm/mach-tegra/tegra2_clocks.c| 19 +- drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/tegra/Kconfig | 19 + drivers/gpu/drm/tegra/Makefile |7 + drivers/gpu/drm/tegra/tegra-dc.c | 630 + drivers/gpu/drm/tegra/tegra-dc.h | 245 + drivers/gpu/drm/tegra/tegra-drv.c | 600 drivers/gpu/drm/tegra/tegra-drv.h | 201 drivers/gpu/drm/tegra/tegra-dsi.c | 145 +++ drivers/gpu/drm/tegra/tegra-encon.c| 406 drivers/gpu/drm/tegra/tegra-fb.c | 355 +++ drivers/gpu/drm/tegra/tegra-gem.c | 425 + drivers/gpu/drm/tegra/tegra-hdmi.c | 994 drivers/gpu/drm/tegra/tegra-hdmi.h | 462 + drivers/gpu/drm/tegra/tegra-host1x.c | 90 ++ drivers/gpu/drm/tegra/tegra-rgb.c | 148 +++ drivers/gpu/drm/tegra/tegra-tvo.c | 152 +++ drivers/i2c/i2c-core.c | 34 + drivers/mfd/tps6586x.c | 105 +++ drivers/regulator/tps6586x-regulator.c |1 + include/drm/drm_fixed.h|1 + include/drm/tegra_drm.h| 40 + include/linux/iommu.h |1 + include/linux/mfd/tps6586x.h |1 + include/linux/of_i2c.h |7 + 30 files changed, 5322 insertions(+), 11 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpu/drm/tegra.txt create mode 100644 Documentation/devicetree/bindings/regulator/tps6586x.txt create mode 100644 drivers/gpu/drm/tegra/Kconfig create mode 100644 drivers/gpu/drm/tegra/Makefile create mode 100644 drivers/gpu/drm/tegra/tegra-dc.c create mode 100644 drivers/gpu/drm/tegra/tegra-dc.h create mode 100644 drivers/gpu/drm/tegra/tegra-drv.c create mode 100644 drivers/gpu/drm/tegra/tegra-drv.h create mode 100644 drivers/gpu/drm/tegra/tegra-dsi.c create mode 100644 drivers/gpu/drm/tegra/tegra-encon.c create mode 100644 drivers/gpu/drm/tegra/tegra-fb.c create mode 100644 drivers/gpu/drm/tegra/tegra-gem.c create mode 100644 drivers/gpu/drm/tegra/tegra-hdmi.c create mode 100644 drivers/gpu/drm/tegra/tegra-hdmi.h create mode 100644 drivers/gpu/drm/tegra/tegra-host1x.c create mode 100644 drivers/gpu/drm/tegra/tegra-rgb.c create mode 100644 drivers/gpu/drm/tegra/tegra-tvo.c create mode 100644 include/drm/tegra_drm.h -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 4/5] drm: fixed: Add dfixed_frac
From: Robert Morell
This helper macro retrieves the fractional part of a fixed20_12 20.12
fixed-point number.
Signed-off-by: Robert Morell
Signed-off-by: Olof Johansson
Signed-off-by: Thierry Reding
---
include/drm/drm_fixed.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_fixed.h b/include/drm/drm_fixed.h
index 4a08a66..0ead502 100644
--- a/include/drm/drm_fixed.h
+++ b/include/drm/drm_fixed.h
@@ -37,6 +37,7 @@ typedef union dfixed {
#define dfixed_init(A) { .full = dfixed_const((A)) }
#define dfixed_init_half(A) { .full = dfixed_const_half((A)) }
#define dfixed_trunc(A) ((A).full >> 12)
+#define dfixed_frac(A) ((A).full & ((1 << 12) - 1))
static inline u32 dfixed_floor(fixed20_12 A)
{
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 1/5] iommu: Include linux/types.h
The linux/iommu.h header uses types defined in linux/types.h but doesn't include it. Signed-off-by: Thierry Reding --- include/linux/iommu.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/iommu.h b/include/linux/iommu.h index d937580..2b2fcdb 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -20,6 +20,7 @@ #define __LINUX_IOMMU_H #include +#include #define IOMMU_READ (1) #define IOMMU_WRITE(2) -- 1.7.10 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 2/5] tps6586x: Add device tree support
This commit adds device tree support for the TPS6586x regulator.
Signed-off-by: Thierry Reding
---
.../devicetree/bindings/regulator/tps6586x.txt | 97 ++
drivers/mfd/tps6586x.c | 105
drivers/regulator/tps6586x-regulator.c |1 +
include/linux/mfd/tps6586x.h |1 +
4 files changed, 204 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/tps6586x.txt
diff --git a/Documentation/devicetree/bindings/regulator/tps6586x.txt
b/Documentation/devicetree/bindings/regulator/tps6586x.txt
new file mode 100644
index 000..0fcabaa3
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps6586x.txt
@@ -0,0 +1,97 @@
+TPS6586x family of regulators
+
+Required properties:
+- compatible: "ti,tps6586x"
+- reg: I2C slave address
+- interrupts: the interrupt outputs of the controller
+- #gpio-cells: number of cells to describe a GPIO
+- gpio-controller: mark the device as a GPIO controller
+- regulators: list of regulators provided by this controller, must be named
+ after their hardware counterparts: sm[0-2], ldo[0-9] and ldo_rtc
+
+Each regulator is defined using the standard binding for regulators.
+
+Example:
+
+ pmu: tps6586x@34 {
+ compatible = "ti,tps6586x";
+ reg = <0x34>;
+ interrupts = <0 88 0x4>;
+
+ #gpio-cells = <2>;
+ gpio-controller;
+
+ regulators {
+ sm0_reg: sm0 {
+ regulator-min-microvolt = < 725000>;
+ regulator-max-microvolt = <150>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sm1_reg: sm1 {
+ regulator-min-microvolt = < 725000>;
+ regulator-max-microvolt = <150>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sm2_reg: sm2 {
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <455>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo0_reg: ldo0 {
+ regulator-name = "PCIE CLK";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-min-microvolt = < 725000>;
+ regulator-max-microvolt = <150>;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-min-microvolt = < 725000>;
+ regulator-max-microvolt = <150>;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-min-microvolt = <125>;
+ regulator-max-microvolt = <330>;
+ };
+
+ ldo4_reg: ldo4 {
+ regulator-min-microvolt = <170>;
+ regulator-max-microvolt = <2475000>;
+ };
+
+ ldo5_reg: ldo5 {
+ regulator-min-microvolt = <125>;
+ regulator-max-microvolt = <330>;
+ };
+
+ ldo6_reg: ldo6 {
+ regulator-min-microvolt = <125>;
+ regulator-max-microvolt = <330>;
+ };
+
+ ldo7_reg: ldo7 {
+ regulator-min-microvolt = <125>;
+ regulator-max-microvolt = <330>;
+ };
+
+ ldo8_reg: ldo8 {
+ regulator-min-microvolt = <125>;
+ regulator-max-microvolt = <330>;
+ };
+
+ ldo9_reg: ldo9 {
+ regulator-min-microvolt = <125>;
+ regulator-max-microvolt = <330>;
+ };
+ };
+ };
diff --git a/drivers/mfd/tps6586x.c b/drivers/mfd/tps6586x.c
index a5ddf31..7614b1b 100644
--- a/drivers/mfd/tps6586x.c
+++ b/drivers/mfd/tps6586x.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -460,6 +461,7 @@ static int __devinit tps6586x_add_subdevs(struct tps6586x
*tps6586x,
pdev->dev.parent = tps6586x->dev;
[RFC v2 3/5] i2c: Add of_i2c_get_adapter() function
This function resolves an OF device node to an I2C adapter registered
with the I2C core.
Signed-off-by: Thierry Reding
---
drivers/i2c/i2c-core.c | 34 ++
include/linux/of_i2c.h |7 +++
2 files changed, 41 insertions(+)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index feb7dc3..e73b044 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1627,6 +1627,40 @@ void i2c_put_adapter(struct i2c_adapter *adap)
}
EXPORT_SYMBOL(i2c_put_adapter);
+#ifdef CONFIG_OF
+static int of_i2c_match_node(int id, void *p, void *data)
+{
+ struct device_node *node = data;
+ struct i2c_adapter *adapter = p;
+
+ if (adapter->dev.of_node == node)
+ return id;
+
+ return 0;
+}
+
+struct i2c_adapter *of_i2c_get_adapter(struct device_node *node)
+{
+ struct i2c_adapter *adapter = NULL;
+ int err;
+
+ mutex_lock(&core_lock);
+
+ err = idr_for_each(&i2c_adapter_idr, of_i2c_match_node, node);
+ if (err < 0)
+ goto out;
+
+ adapter = idr_find(&i2c_adapter_idr, err);
+ if (adapter && !try_module_get(adapter->owner))
+ adapter = NULL;
+
+out:
+ mutex_unlock(&core_lock);
+ return adapter;
+}
+EXPORT_SYMBOL(of_i2c_get_adapter);
+#endif
+
/* The SMBus parts */
#define POLY(0x1070U << 3)
diff --git a/include/linux/of_i2c.h b/include/linux/of_i2c.h
index 0efe8d4..a35c497 100644
--- a/include/linux/of_i2c.h
+++ b/include/linux/of_i2c.h
@@ -20,11 +20,18 @@ extern void of_i2c_register_devices(struct i2c_adapter
*adap);
/* must call put_device() when done with returned i2c_client device */
extern struct i2c_client *of_find_i2c_device_by_node(struct device_node *node);
+extern struct i2c_adapter *of_i2c_get_adapter(struct device_node *node);
+
#else
static inline void of_i2c_register_devices(struct i2c_adapter *adap)
{
return;
}
+
+static inline struct i2c_adapter *of_i2c_get_adapter(struct device_node *node)
+{
+ return NULL;
+}
#endif /* CONFIG_OF_I2C */
#endif /* __LINUX_OF_I2C_H */
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] eepromer/24cXX: fix leaking file descriptor
Jean Delvare writes:
> Hi Nikola,
>
> Patches for i2c-tools are better sent to the linux-i2c list,
> redirecting.
>
> On Tue, 24 Apr 2012 12:24:54 +0200, Nikola Pajkovsky wrote:
>> Signed-off-by: Nikola Pajkovsky
>> ---
>> eepromer/24cXX.c |5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/eepromer/24cXX.c b/eepromer/24cXX.c
>> index 00a21fd..ab86c33 100644
>> --- a/eepromer/24cXX.c
>> +++ b/eepromer/24cXX.c
>> @@ -79,9 +79,10 @@ int eeprom_open(char *dev_fqn, int addr, int type, struct
>> eeprom* e)
>> return -1;
>>
>> // get funcs list
>> -if((r = ioctl(fd, I2C_FUNCS, &funcs) < 0))
>> +if((r = ioctl(fd, I2C_FUNCS, &funcs) < 0)) {
>> +close(fd);
>> return r;
>> -
>> +}
>>
>> // check for req funcs
>> CHECK_I2C_FUNC( funcs, I2C_FUNC_SMBUS_READ_BYTE );
>
> Good catch, however this function is leaking the same file descriptor
> in 7 other cases (one obvious one plus six times in CHECK_I2C_FUNC.) If
> we fix one, we should fix them all. I'd also be happy to get rid of
> CHECK_I2C_FUNC as it exists, macro-generated code is evil. I see no
> good reason why this couldn't be implemented as a regular function
> instead.
>
> Will you send updated patches, or do you want me to take care of these
> changes?
aha, I didn't look at it so deeper. Nevertheless I'll prepare another
patches.
--
Nikola
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
