> From: Lucas Stach [mailto:l.stach@xxxxxxxxxxxxxx] > Sent: Wednesday, February 20, 2019 8:11 PM > > Am Mittwoch, den 20.02.2019, 11:21 +0000 schrieb Aisheng Dong: > > Hi Marco, > > > > > From: Marco Felsch [mailto:m.felsch@xxxxxxxxxxxxxx] > > > Sent: Wednesday, February 20, 2019 6:53 PM > > > > > > Hi Aisheng, > > > > > > On 19-02-20 09:49, Aisheng Dong wrote: > > > > > From: Marco Felsch [mailto:m.felsch@xxxxxxxxxxxxxx] > > > > > Sent: Wednesday, February 20, 2019 4:17 PM On 19-02-20 03:38, > > > > > Aisheng Dong wrote: > > > > > > [...] > > > > > > > > > > > > > > I don't like droping some ID's (e.g. > > > > > > > > IMX_SC_R_DC_0_CAPTURE0) by mark them as unused or even > > > > > > > > worse give them a other meaning. IMHO the scu-api should > > > > > > > > be stable since day 1 and the ID's should only be > > > > > extended. > > > > > > > > Marking ID's as deprecated is much better than moving them > around. > > > > > > > > > > > > > > I agree the SCU APIs should be stable since day 1 and the ID > > > > > > > should ONLY be extended, but that is the best cases, the > > > > > > > reality is, there are different SoCs/Revision, some > > > > > > > revisions may remove the resources ID defined in pre-coded > > > > > > > SCU firmware, like the > > > > > > > IMX_SC_R_DC_0_CAPTURE0 etc., so SCU APIs removes them after > > > > > > > real silicon arrived, now latest SCU firmware marks them as > > > > > > > UNUSED, they could be replaced by some other new resources > > > > > > > in later new SoC, I am NOT sure, but if it happens, this > > > > > > > resource ID table should be updated anyway, leaving the > > > > > > > out-of-date resource ID table there will have > > > > > issues, since it is NOT sync with SCU firmware. > > > > > > > So how to resolve such issue? We hope the SCU firmware > > > > > > > should be stable since day 1, but the truth is NOT, could be > > > > > > > still some updates but NOT very often. And I believe the > > > > > > > updates will NOT break old > > > > > kernel version. > > > > > > > > > > Hi Anson, > > > > > > > > > > Please don't mix the dt-bindings and the kernel related stuff. > > > > > Unfortunately the bindings are within the kernel repo which in > > > > > fact is great for us kernel developer but the bindings are also > > > > > used in other projects such as barebox or other kernels (don't > > > > > know the BSD guys). So you can't ensure that your change will > > > > > break something. Please > > > keep that in mind. > > > > > IMHO solving that issue should be done by the scu firmware. I > > > > > tought the scu is a cortex-m4 with a bunch of embedded flash and > > > > > ram (I don't know that much about the scu since it is > closed/black-boxed). > > > > > Why do you don't use a translation table within the scu? As I > > > > > said earlier I don't like the redefinition of ID's since they > > > > > are now part of the > > > dt-bindings. > > > > > The bindings can store up to 32bit values which is a large > > > > > number ;) IMHO wasting some ID's in favour of stability is a better > solution. > > > > > > > > > > > > > As far as I know, those remove resource IDs are pre-defined and > > > > has never been used and won't be used anymore by SC firmware. > > > > (Anson can double check it) So I think it's safe to remove them or > > > > mark them as > > > deprecated. > > > > > > I think marking them as deprecated by a commentar is better than > > > redefining bits to be unused. As I said the bindings not only linux > > > related they are used in other projects too. > > > > > > > For other projects, the result is same because SC firmware does not > > support those Resource IDs. > > > > > > Personally I may prefer to remove them as they never worked to > > > > avoid confusing, especially at this early stage for mx8. > > > > > > So why they are there if they never worked? Wouldn't it a better > > > approach to start with a basic and working ID file and extend this > > > rather than adding id's because maybe the will work.. > > > > Ideally yes, but may be hard in reality. > > > > SC firmware code usually is developed quite early before silicon comes. > > But the real chip may changes, e.g. removed or added something. > > > > AFAIK those resource IDs removed have never worked in SC firmware, and > > they're likely to come out of pre-silicon definition. But chip changes > > later. > > > > > Sorry but this seems wrong to me too. > > > I know the approach from driver development, adding a driver > > > specific *_reg.h file and later figuring out that those bits won't > > > work as aspected. As I said this will be driver and only linux > > > related so we can change them as many times as we want. But in your > > > case we are talking about dt-bindings and this approach won't work. > > > > I would agree with you if those resource IDs have worked before. > > But they never worked. > > Should we keep a thing never worked in device tree just because It > > makes us look like keeping compatibility? > > > > If that, I'd rather removing them to avoid confusing in the future. Life is long, > right? > > I don't want people to bother with those unmeaning things anymore when > > they look at it. > > Removing things is totally fine if they have never worked. Re-using the now > "free" IDs is what is problematic. Only ever use previously unused IDs when > introducing new stuff into the SCU firmware. This is something you need to > communicate quite clearly with the SCU firmware developers. > Yes, that's right. I will forward this request to them. Thanks for the info. Regards Dong Aisheng > Regards, > Lucas
