On 10/01/2014 01:43 PM, Wolfram Sang wrote: > >>> 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 > >> ...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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
