On 9/8/2011 9:56 AM, Ohad Ben-Cohen wrote:
Hi Benoit,
On Thu, Sep 8, 2011 at 10:14 AM, Cousson, Benoit<b-cousson@xxxxxx> wrote:
Hehe, I'm not the one who wrote that driver :-)
This is not wrong for the current HW. The point is do we want to anticipate
potential HW evolution that might never happen on that IP?
I originally really thought we can ignore those cases (hence the 0
base id ;), and personally I still think the scenario is a bit
fictional, and wouldn't even mind just having omap_hwspinlock_probe()
return an error if it is unexpectedly probed with a second device.
But if fixing this entirely only means doing a small change, then it's
surely nicer.
That should not be a big deal to add that kind of support.
This is no different than the multiple GPIO controllers we have today.
Since we cannot rely on the DT nodes order, I added an explicit "id"
attribute to provide that information to the driver. And then the baseid is
"id * #gpios".
That would work if #hwspinlock is a fixed number, but a "baseid"
attribute would allow supporting devices with different #hwspinlocks
per device. Since I am not aware of any real hardware that does this
kind of blasphemy, I can't say if the latter is really necessary :) If
you prefer the former, I'm entirely fine with it.
The (small) issue for my point of view is that the #hwspinlock is
already encoded in the IP itself. So adding a baseid directly in DT will
look like duplicating indirectly something that is already there in the HW.
That being said, since we cannot rely on the order, we will not be able
to get the proper baseid until the driver probe every hwspinlock devices
:-(
So baseid might be a easier choice.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
