Re: shamcop adc

Hello,

Thanks for the quick answer.

Selon Phil Blundell <pb_at_nexus.co.uk>:

> The irq code in shamcop_probe has a typo. That line should read:
>
> res[2].end = res[2].start;

I was wondering that. So I comment the old but with no success.

>
> However, that won't actually fix the problem, because the shamcop parent
> doesn't have any corresponding resource that would contain the irq
> allocations. I imagine this code has also been broken on h5400 since
> Andrew added the extra checking in soc_device_register().

Yes it does not fix the problem, but I do not uderstand how can I make it work if
the shamcop parent doesn't have the corresponding resource.

>
> This area of SoC resource handling is all a bit murky, and it needs a
> bit more thought. What's really needed is a way for shamcop_base (and
> similar top-level SoC containers) to award themselves new resource
> ranges for virtual irqs and other things that they have allocated
> internally. But pdev->resource is statically allocated, so they can't
> just poke at that, and in any case it's rather gruesome for soc-device
> to be tangled up with platform devices in this way. (There's no reason
> that a SoC container couldn't be placed on a PCI card, or in some other
> situation where its parent was a non-platform device.)
>
> For the time being, I suggest that you just defeat soc_device_register's
> containedness check in your local tree. We'll have to try to come up
> with a proper fix in due course.

Yes I can do that but then I get a message saying it cannot claim the resource.
And the
device adc shamcop cannot be defined without parent (I get a kernel oops).

I have also reading the 2.4 kernel but I don't see exactly where the touchscreen was
managed.

Thanks again,

Alain
Received on Tue Mar 02 2004 - 16:34:02 EST