Hi, On Sun, May 11, 2014 at 6:52 PM, Pankaj Dubey <pankaj.dubey@xxxxxxxxxxx> wrote: > On 05/11/2014 04:12 PM, Olof Johansson wrote: >> >> Hi, >> >> On Sat, May 10, 2014 at 12:18 AM, <y@xxxxxxxxxxx> wrote: >>> >>> From: Pankaj Dubey <pankaj.dubey@xxxxxxxxxxx> >>> >>> This patch series attempts to get rid of soc_is_exynosXXXX macros >>> and eventually with the help of this series we can probably get >>> rid of CONFIG_SOC_EXYNOSXXXX in near future. >>> Each Exynos SoC has ChipID block which can give information about >>> SoC's product Id and revision number. Currently we have single >>> DT binding information for this as "samsung,exynos4210-chipid". >>> But Exynos4 and Exynos5 SoC series have one small difference in >>> chip Id, with resepect to product id bit-masks. So it means we >>> should have separate compatible string for these different series >>> of SoCs. So I have added second compatible string for handling >>> this difference. >>> This patch series is based on Kukjin Kim's for-next (3.14_rc1 tag) >>> and prepared on top of following patch series and it's dependent >>> patch series. >>> >>> [1]: Map SYSRAM through generic SRAM bindings by Sachin Kamat. >>> http://www.spinics.net/lists/arm-kernel/msg327677.html >>> [2]: Exynos PMU cleanup and refactoring. >>> https://lkml.org/lkml/2014/4/30/44 >>> [3]: Introduce drivers/soc and add QCOM GSBI driver. >>> https://lkml.org/lkml/2014/4/24/520 >>> >>> Revision 2 and it's discussion can be found here >>> - https://lkml.org/lkml/2014/5/6/100 >> >> As I just realized when I commented on the last patch in the patchset >> (the cpufreq section): I think you can, and should, use >> of_machine_is_compatible() for most of these cases, instead of using a >> new API through a chipid driver. Since all boards based on an SoC >> should have that in the string of compatibles, it's a shared and easy >> way to handle this without adding custom drivers per manufacturer. > > I am sorry, I could not see your comments in my last patch-set. > > Anyway, thanks for review. During first version of this patch, I had > discussion with Arnd [1], and it looks like he do not like idea of using > "of_machine_is_compatible". > > [1]: https://lkml.org/lkml/2014/5/5/126 > and > https://lkml.org/lkml/2014/5/5/335 Ok, I've commented on that thread now. > So my proposal was till we get generic solution for all files > under mach-exynos let's use chip-id driver provided APIs. of_machine_is_compatible() is a quite sensible existing generic interface to do this. We don't need to add a driver for it. > Also chip-id driver is not only for providing this API but also > to provide SoC specific information as a sysfs entry to userspace. > So even though we do not want to use chipid driver API's > for identifying SoCs we can keep this driver. For this you might want a chipid driver, yes. I'm mostly objecting to the addition of the new is_soc_.*() API, not the introduction of the driver for that purpose. > So let us discuss again and decide which will be best way > (at the same time less overhead) solution for removing usage > of soc_is_exynosXYZ and related CONFIG macros from exynos. > @Arnd and Tomasz, I would appreciate if you spent some time > to review this series as I have addressed many of your > review comments. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |