Thread (35 messages) 35 messages, 4 authors, 2014-10-01

Re: [PATCH v2 2/3] net: can: c_can: Add syscon/regmap RAMINIT mechanism

From: Roger Quadros <hidden>
Date: 2014-10-01 10:58:20
Also in: linux-can, linux-omap

On 10/01/2014 01:43 PM, Wolfram Sang wrote:
quoted
quoted
Unfortunately it is 5 ;)
We have display IP related bit in between 3 and 5 :P
What on earth were the HW engineers thinking????????????
"Let's test my RNG on the bit-placement of this register" :)
:D
quoted
...if we just have the instance parameter in the syscon phandle, we have
to put the mapping into the driver, which makes IMHO no sense, because
you have to touch the driver, if there is another SoC with the DCAN core.
My guess is that TI won't come up with a 3rd variant so we won't have to
touch the driver, but you never know for sure.
... which would be my preferred solution. I think new SoCs should have
some kind of:

	compatible = "commodore,c64ultra", "bosch,d_can";

in the DT anyhow to allow for SoC specific quirks/adjustments. And
custom raminit belongs to that IMO (see the ti routine getting more and
more specific).
Right. For now we need 2 start/stop definations for the existing TI Socs.

but where to store the raminit start/stop bits? The driver_data currently seems to 
contain the CAN type C_CAN vs D_CAN without containing it in a platform_data structure.

Is it OK to create a new platform_data structure for CAN and put the type and raminit start/stop
bits there?

cheers,
-roger
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help