Jon Smirl said the following:
> So a solution might lie down the path of having whatever catches the
> hotplug event (pci, usb, ..) run code that modifies the device tree
> and inserts the new i2c nodes. After the device tree has been modified
> trigger a rescan of devices so that the i2c drivers g
On Tue, Apr 21, 2009 at 12:33 PM, Jean Delvare wrote:
> On Tue, 21 Apr 2009 12:00:02 -0400, Jon Smirl wrote:
>> On Tue, Apr 21, 2009 at 10:11 AM, Michael Lawnick wrote:
>> > Jean Delvare said the following:
>> >> You apparently still have a hard time differentiating between devices
>> >> and driv
Hi Linus,
Please pull the i2c subsystem fixes for Linux 2.6.30 from:
git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus
drivers/staging/go7007/go7007-driver.c | 11 +++-
drivers/staging/go7007/go7007-i2c.c | 83 ---
drivers/staging/go7007/go7007-priv.h
On Tue, 21 Apr 2009 12:00:02 -0400, Jon Smirl wrote:
> On Tue, Apr 21, 2009 at 10:11 AM, Michael Lawnick wrote:
> > Jean Delvare said the following:
> >> You apparently still have a hard time differentiating between devices
> >> and drivers. Loading modules at runtime != instantiating devices at
>
On Tue, Apr 21, 2009 at 10:11 AM, Michael Lawnick wrote:
> Jean Delvare said the following:
>> You apparently still have a hard time differentiating between devices
>> and drivers. Loading modules at runtime != instantiating devices at
>> runtime.
>>
> Well, till now I assumed that you can't insta
On Apr 21, 2009, at 7:49 AM, Mark Ware wrote:
Recent DMA changes result in a BUG() when NULL is passed to
dma_alloc_coherent in place of a device.
Signed-off-by: Mark Ware
---
This patch fixes the BUG() during boot that has appeared during the
2.6.30 window. It has been tested and appears co
Wolfgang Grandegger said the following:
>> Many adapters do initialization of .class in adapter code. A few do not.
>> I haven't checked, but assume the PPC ones, as they have DTS. Thats Ok,
>> as long DTS is really used. In at least one other adapter it is: Exactly
>> Wolfgang Grandegger, who is r
Jean Delvare said the following:
> You apparently still have a hard time differentiating between devices
> and drivers. Loading modules at runtime != instantiating devices at
> runtime.
>
Well, till now I assumed that you can't instantiate a device who's
driver isn't loaded. But I am eager to lear
Mark Ware schrieb:
> Recent DMA changes result in a BUG() when NULL is passed to
> dma_alloc_coherent in place of a device.
This seems to have happened in 4ae0ff606e848fa4957ebf8f97e5db5fdeec27be.
> Signed-off-by: Mark Ware
Acked-by: Jochen Friedrich
Thanks,
Jochen
--
To unsubscribe from this
Michael Lawnick wrote:
> Wolfram Sang said the following:
>>> mailing list. Nevertheless loading modules at runtime is legal and
>>> generally supported by LINUX.
>> Ack. And it does so...
>>
>>> Defining all possible (I2C-)devices in DTS would give a mess. E.g. on
>>> one board there will be ~30 t
Wolfram Sang said the following:
>> mailing list. Nevertheless loading modules at runtime is legal and
>> generally supported by LINUX.
>
> Ack. And it does so...
>
>> Defining all possible (I2C-)devices in DTS would give a mess. E.g. on
>> one board there will be ~30 temperature sensors, on the
>
> On 21/4/09, Guennadi Liakhovetski wrote:
>> On Tue, 21 Apr 2009, Agustin wrote:
>> >
>> > Hi,
>> >
>> > On 21/4/09, Guennadi Liakhovetski wrote:
>> > > Video (sub)devices, connecting to SoCs over generic i2c busses
>> cannot
>> > > provide a pointer to struct v4l2_device in i2c-adapter drive
Recent DMA changes result in a BUG() when NULL is passed to
dma_alloc_coherent in place of a device.
Signed-off-by: Mark Ware
---
This patch fixes the BUG() during boot that has appeared during the
2.6.30 window. It has been tested and appears correct on my 8280 based
board.
Sent to both linuxp
On 21/4/09, Guennadi Liakhovetski wrote:
> On Tue, 21 Apr 2009, Agustin wrote:
> >
> > Hi,
> >
> > On 21/4/09, Guennadi Liakhovetski wrote:
> > > Video (sub)devices, connecting to SoCs over generic i2c busses cannot
> > > provide a pointer to struct v4l2_device in i2c-adapter driver_data, and
Jean Delvare wrote:
> On Tue, 21 Apr 2009 12:35:49 +0200, Wolfgang Grandegger wrote:
>> Michael Lawnick wrote:
>>> Wolfgang Grandegger said the following:
Do we really need that? Probing is dangerous and not necessary. Does it
not work with a proper DTS entry? But maybe I have missed some
On Tue, 21 Apr 2009 12:35:49 +0200, Wolfgang Grandegger wrote:
> Michael Lawnick wrote:
> > Wolfgang Grandegger said the following:
> >> Do we really need that? Probing is dangerous and not necessary. Does it
> >> not work with a proper DTS entry? But maybe I have missed something?
> >
> > Our cur
Michael Lawnick wrote:
> Wolfgang Grandegger said the following:
>> Hello,
>>
>> sorry for jumping in late. I just recently subscribed to this list.
>>
>> Michael Lawnick wrote:
>>> For MPC adapter there is no class assigned as it is done in other
>>> adapters. This way no new-style client will eve
On Tue, 21 Apr 2009 11:26:10 +0200, Michael Lawnick wrote:
> Wolfgang Grandegger said the following:
> > Hello,
> >
> > sorry for jumping in late. I just recently subscribed to this list.
> >
> > Michael Lawnick wrote:
> >> For MPC adapter there is no class assigned as it is done in other
> >> ad
> mailing list. Nevertheless loading modules at runtime is legal and
> generally supported by LINUX.
Ack. And it does so...
> Defining all possible (I2C-)devices in DTS would give a mess. E.g. on
> one board there will be ~30 temperature sensors, on the other none.
> As every DTS entry will forc
Wolfgang Grandegger said the following:
> Hello,
>
> sorry for jumping in late. I just recently subscribed to this list.
>
> Michael Lawnick wrote:
>> For MPC adapter there is no class assigned as it is done in other
>> adapters. This way no new-style client will ever be instantiated. With
>> thi
On Tue, 21 Apr 2009 09:22:38 +0200 (CEST), Guennadi Liakhovetski wrote:
> Currently drivers/media drivers are linked very early - directly after
> base, block, misc, and mfd and before ata, scsi, ide, input, firewire,
> usb, and i2c. This breaks static build of video4linux drivers, that use
> ge
On Tue, 21 Apr 2009 08:42:27 +0200, Michael Lawnick wrote:
> For MPC adapter there is no class assigned as it is done in other
> adapters. This way no new-style client will ever be instantiated.
This statement is incorrect. How many times will I have to repeat
myself?
> With
> this patch class as
> For MPC adapter there is no class assigned as it is done in other
> adapters.
Still, the trend is to use the class field less, not more often. Probing
causes more pain than gain. Most of us have been through that, try to
believe us.
> This way no new-style client will ever be instantiated.
So
Currently drivers/media drivers are linked very early - directly after
base, block, misc, and mfd and before ata, scsi, ide, input, firewire,
usb, and i2c. This breaks static build of video4linux drivers, that use
generic CPU i2c adapter drivers and the v4l2-subdev subsystem, because
during vid
Michael Lawnick wrote:
> Wolfram Sang said the following:
>>> Could you please elaborate?
>> Instead of probing you specify the devices on the i2c-bus in the dts. Example
>> for the pcm032 looks like this (from the kernel-tree):
>>
>> i...@3d40 {
>> #address-cells = <1>;
>> #size-cells =
Hello,
sorry for jumping in late. I just recently subscribed to this list.
Michael Lawnick wrote:
> For MPC adapter there is no class assigned as it is done in other
> adapters. This way no new-style client will ever be instantiated. With
> this patch class assignment is read from device tree.
>
26 matches
Mail list logo
