Re: [PATCH] tty/serial: fix config dependencies for samsung serial

[Naveen Krishna Ch]

Hi Arnd,

On 2 September 2014 21:16, Arnd Bergmann  wrote:
> On Tuesday 02 September 2014 20:52:00 Naveen Krishna Chatradhi wrote:
>> Make the config symbols SERIAL_SAMSUNG_UARTS_4 and
>> SERIAL_SAMSUNG_UARTS depend on SERIAL_SAMSUNG rather than
>> PLAT_SAMSUNG.
>
> Please always describe why you are doing a change. This patch
> seems really pointless.

The SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS config options are
meaningful only if SERIAL_SAMSUNG is enabled. Hence the dependency
rules were changed. I will repost this patch with better description.

>
>>  config SERIAL_SAMSUNG_UARTS_4
>> bool
>> -   depends on PLAT_SAMSUNG
>> +   depends on SERIAL_SAMSUNG
>> default y if !(CPU_S3C2410 || CPU_S3C2412 || CPU_S3C2440 || 
>> CPU_S3C2442)
>> help
>>   Internal node for the common case of 4 Samsung compatible UARTs
>>
>>  config SERIAL_SAMSUNG_UARTS
>> int
>> -   depends on PLAT_SAMSUNG
>> +   depends on SERIAL_SAMSUNG
>> default 4 if SERIAL_SAMSUNG_UARTS_4 || CPU_S3C2416
>> default 3
>> help
>>
>
> Have you checked that it still builds on all samsung platforms when
> SERIAL_SAMSUNG is disabled? We have had build errors in this area
> in the past.

Yes, it builds for other Samsung platforms.

>
> Arnd

Thanks.

-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv6 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean

[Naveen Krishna Ch]

Hello All,

On 18 July 2014 15:43, Naveen Krishna Ch  wrote:
> Hello Arnd,
>
> On 18 July 2014 15:08, Arnd Bergmann  wrote:
>> On Friday 18 July 2014 14:59:42 Chanwoo Choi wrote:
>>> This patchset support Exynos3250 ADC (Analog Digital Converter) because
>>> Exynos3250 has additional special clock for ADC IP.
>>>
>>
>> by coincidence, I have just looked at the same driver in order to
>> add support for s3c24xx and s3c64xx, so we can remove the plat-samsung
>> adc framework they still use.  Those changes would naturally conflict
>> with yours, but I think it makes sense for your patches to come first.
>>
>> I'll comment a bit more on the individual patches. I didn't have
>> interest in them earlier, so I didn't comment so far.
>>
>> Another aspect that came up is the touchscreen support. Right now,
>> there is drivers/input/touchscreen/s3c2410_ts.c which is intimately
>> tied to arch/arm/plat-samsung/adc.c. The best way forward (as discussed
>> on IRC as few days ago) seems to be to integrate support for that into
>> the exynos_adc driver. Can you comment on which parts actually support
>> touchscreen? Did touchscreen support get dropped in the exynos hardware,
>> or is the driver just missing at the moment?
>
> SoCs from Samsung before Exynos4 had and ADC based Touch screen
> and the driver under arch/arm/plat-samsung/adc.c and
> drivers/input/touchscreen/s3c2410_ts.c used to work together.
>
> Infact, the interrupt routine and priorities in plat-samsung/adc.c
> driver as written keeping the Touchscreen in mind.
>
> After Exynos4, ADC IP remained. But, the touch screen was removed in hardware.

At least on Exynos4210> i'm not sure about the other Exynos4 series.
I will try to verify the user manuals.

>
> As per suggestion from Doug Anderson, I've implemented IIO based ADC
> driver started to support from exynos5250.
>
>>
>> Arnd
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Shine bright,
> (: Nav :)



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv6 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean

[Naveen Krishna Ch]

Hello Arnd,

On 18 July 2014 15:08, Arnd Bergmann  wrote:
> On Friday 18 July 2014 14:59:42 Chanwoo Choi wrote:
>> This patchset support Exynos3250 ADC (Analog Digital Converter) because
>> Exynos3250 has additional special clock for ADC IP.
>>
>
> by coincidence, I have just looked at the same driver in order to
> add support for s3c24xx and s3c64xx, so we can remove the plat-samsung
> adc framework they still use.  Those changes would naturally conflict
> with yours, but I think it makes sense for your patches to come first.
>
> I'll comment a bit more on the individual patches. I didn't have
> interest in them earlier, so I didn't comment so far.
>
> Another aspect that came up is the touchscreen support. Right now,
> there is drivers/input/touchscreen/s3c2410_ts.c which is intimately
> tied to arch/arm/plat-samsung/adc.c. The best way forward (as discussed
> on IRC as few days ago) seems to be to integrate support for that into
> the exynos_adc driver. Can you comment on which parts actually support
> touchscreen? Did touchscreen support get dropped in the exynos hardware,
> or is the driver just missing at the moment?

SoCs from Samsung before Exynos4 had and ADC based Touch screen
and the driver under arch/arm/plat-samsung/adc.c and
drivers/input/touchscreen/s3c2410_ts.c used to work together.

Infact, the interrupt routine and priorities in plat-samsung/adc.c
driver as written keeping the Touchscreen in mind.

After Exynos4, ADC IP remained. But, the touch screen was removed in hardware.

As per suggestion from Doug Anderson, I've implemented IIO based ADC
driver started to support from exynos5250.

>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv6 1/4] iio: adc: exynos_adc: Add exynos_adc_data structure to improve readability

[Naveen Krishna Ch]

Hello Arnd,

On 18 July 2014 15:12, Arnd Bergmann  wrote:
> On Friday 18 July 2014 14:59:43 Chanwoo Choi wrote:
>> This patchset add 'exynos_adc_data' structure which includes some functions
>> to control ADC operation and specific data according to ADC version (v1 or 
>> v2).
>>
>
> This new structure makes a lot of sense for covering the exynos specific
> versions, but it will likely give a little more complexity for the
> older models. We'll have to deal with that later then, no need to
> hold up your patch. Interestingly, the version numbers seem weird. The
> old driver uses
>
> {
> .name   = "s3c24xx-adc",
> .driver_data= TYPE_ADCV1,
> }, {
> .name   = "s3c2443-adc",
> .driver_data= TYPE_ADCV11,
> }, {
> .name   = "s3c2416-adc",
> .driver_data= TYPE_ADCV12,
> }, {
> .name   = "s3c64xx-adc",
> .driver_data= TYPE_ADCV2,
> }, {
> .name   = "samsung-adc-v3",
> .driver_data= TYPE_ADCV3,
> }
>
> Where TYPE_ADCV3 seems to be the same as the new ADC_V1 used in this
> driver. Do you have an explanation for that?

As per suggestion from Doug Anderson,
I've implemented IIO based ADC driver to work with Exynos5250.
keeping the plat-samsung/adc.c unchanged.

Assuming Exynos5250 is the one using the driver for the first time.
i've named it v1 and so on.

Now, This seems to cause a lot of confusion.

>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4 v2] iio: exyno-adc: use syscon for PMU register access

[Naveen Krishna Ch]

Hello Sachin,

On 17 July 2014 17:24, Sachin Kamat  wrote:
> Hi Naveen,
>
> On Thu, Jul 17, 2014 at 4:49 PM, Naveen Krishna Chatradhi
>  wrote:
>> This patch updates the IIO based ADC driver to use syscon and regmap
>> APIs to access and use PMU registers instead of remapping the PMU
>> registers in the driver.
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> To: linux-...@vger.kernel.org
>
> With only this patch applied, I believe the ADC functionality would be broken.
> Perhaps the DT changes should be merged along with this patch?

Jonathan already mentioned that, he would wait for Ack from Kukjin.
With out the dts changes ADC driver will fail to probe but it wont
crash the system.
git bisect should still work.

>
> --
> Regards,
> Sachin.



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/4] iio: exynos-adc: use syscon instead of ioremap

[Naveen Krishna Ch]

Hello Jonathan,

On 15 July 2014 23:45, Jonathan Cameron  wrote:
> On 15/07/14 19:13, Jonathan Cameron wrote:
>>
>> On 11/07/14 10:06, Naveen Krishna Chatradhi wrote:
>>>
>>> This patch does the following
>>> 1. Use the syscon and Regmap API instead of ioremappaing the
>>> ADC_PHY register from PMU.
>>> 2. Moves the exynos-adc.txt from bindings/arm/samsung/
>>> to bindings/iio/adc/.
>>> 3. Updates the Documentation in exynos-adc.txt with syscon phandle
>>> for the ADC nodes.
>>> 4. Updates the Dts files for Exynos3250, Exynos4x12, Exynos5250,
>>> Exynos5420 with the syscon phandle.
>>>
>>> Tested on Exynos5420 based Peach PIT and Exynos5800 based Peach PI
>>> by verifying sysfs entries provided by HWMON based NTC thermistors.
>>>
>>> Tested-By for Exynos3250, Exynos4x12 would be appreciated.
>>>
>> This series all looks fine to me.  Took me a minute to work out what the
>> point
>> of the syscon change was (perhaps a little description in the cover letter
>> would have been nice ;)
>>
>> Anyhow, with the device tree changes in here we'll have to let it sit for
>> a while.  I'll also definitely want an ack from
>> Kukjin Kim  for the device tree changes.
>
> Although I haven't tried it, I'd imagine this might cause a little bit
> of merging fun with the other exynos series waiting for Kukjin to
> ack...

I've tried to rebase on top of Chongwoo's v5 version changes for Exynos5320.
there is one conflict with Documentation. I've submitted the v2 version.

> [PATCHv5 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean
>>
>>
>> Jonathan
>>>
>>> Naveen Krishna Chatradhi (4):
>>>iio: exyno-adc: use syscon for PMU register access
>>>Documentation: dt-bindings: move exynos-adc.txt to more iio/adc/
>>>Documentation: dt-bindings: update exynos-adc.txt with syscon handle
>>>ARM: dts: exynos: Add sysreg phandle to ADC node
>>>
>>>   .../devicetree/bindings/arm/samsung/exynos-adc.txt |   82
>>> --
>>>   .../devicetree/bindings/iio/adc/exynos-adc.txt |   87
>>> 
>>>   arch/arm/boot/dts/exynos3250.dtsi  |3 +-
>>>   arch/arm/boot/dts/exynos4x12.dtsi  |3 +-
>>>   arch/arm/boot/dts/exynos5250.dtsi  |3 +-
>>>   arch/arm/boot/dts/exynos5420.dtsi  |3 +-
>>>   drivers/iio/adc/exynos_adc.c   |   29 +--
>>>   7 files changed, 115 insertions(+), 95 deletions(-)
>>>   delete mode 100644
>>> Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>>>   create mode 100644
>>> Documentation/devicetree/bindings/iio/adc/exynos-adc.txt
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>



-- 
Regards,
(: Naveen :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/4] Documentation: dt-bindings: move exynos-adc.txt to more iio/adc/

[Naveen Krishna Ch]

Hello Sachin,

On 11 July 2014 14:47, Sachin Kamat  wrote:
> Hi Naveen,
>
> On Fri, Jul 11, 2014 at 2:36 PM, Naveen Krishna Chatradhi
>  wrote:
>> The DT bindings in exynos-adc.txt applies to the ADC
>> driver (exynos-adc.c) developed based on IIO framework.
>>
>> The bindings are more appropriate to be under
>> Documentation/devicetree/bindings/iio/adc/
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> To: devicet...@vger.kernel.org
>> ---
>>  .../devicetree/bindings/arm/samsung/exynos-adc.txt |   82 
>> 
>>  .../devicetree/bindings/iio/adc/exynos-adc.txt |   82 
>> 
>>  2 files changed, 82 insertions(+), 82 deletions(-)
>>  delete mode 100644 
>> Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
>>  create mode 100644 Documentation/devicetree/bindings/iio/adc/exynos-adc.txt
>>
>
> Tip: For only a file move or rename please use "-M" with git
> format-patch. That will make the
> patch concise.

Sure, Thanks.
>
> --
> Regards,
> Sachin.



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 0/4] ARM: Exynos: PMU cleanup and refactoring for using DT

[Naveen Krishna Ch]

Hello Pankaj,

On 9 July 2014 09:30, Pankaj Dubey  wrote:
> This patch series, modifies Exynos Power Management Unit (PMU) related code
> for converting it into a platform_driver. This is also preparation for moving
> PMU related code out of machine folder into a either "drivers/mfd", or
> "drivers/power" or some other suitable place so that ARM64 based SoC can
> utilize common piece of code.
>
> These patches are created on top of Kukjin Kim's for-next.
> I have tested this patches on Exynos5250 Snow board for system boot and S2R.
>
> This patch series depends on following two patch series:
> [1]: mfd: syscon: Decouple syscon interface from syscon devices.
>  https://lkml.org/lkml/2014/6/24/188
>
> [2]: Cleanup patches for mach-exynos.
>  http://www.spinics.net/lists/arm-kernel/msg341474.html

With the above mentioned patches + this series
I was able to add PMU registers using syscon in the DTS node for DP and ADC.
and access the PMU registers in the respective drivers using syscon API.

Tested-by: Naveen Krishna Chatradhi 

>
> Patch v6 and discussion can be found here:
> https://lkml.org/lkml/2014/7/7/22
>
> Change since v6:
>  - Removed NULL check for pmu_data in pmu.c.
>  - Moved pmu_raw_readl and pmu_raw_writel inline helper function
>into common.h.
>
> Change Since v5:
>  - Squashed patch "Move "mach/map.h" inclusion from regs-pmu.h to platsmp.c"
>into patch "Refactored code for using PMU address via DT".
>  - Addressed review comments from Tomasz Figa.
>  - Using init_irq machine function to initialize PMU mapping instead
>of init_time.
>  - Rebased on latest Kukjin Kim's for-next branch.
>
> Changes Since v4:
>  - Splitted patch series in two parts. Part 1 has code cleanup under 
> mach-exynos
>and posted as separate patch [2]. Current patchset is part 2 which modified
>exynos pmu implementation for making it platform driver.
>  - Removed dependency over early_syscon API.
>  - Removed usage of regmap read/write APIs.
>  - Modified probe function to register exynos pmu as syscon provider using
>Tomasz Figa's syscon patch [1].
>  - Address various other review comments from Tomasz Figa.
>  - Removed signed-off-by of Young-Gun Jang ,
>as this id is no more valid. Taking ownership of all his patches.
>
> Changes Since v3:
>  - Optimized exynos_pmu_probe function by removing exynos_pmu_data_init
>as suggested by Vikas Sajjan.
>  - Modified syscon_early_regmap_lookup_by_phandle and
>syscon_regmap_lookup_by_phandle function call to pass property as NULL.
>
> Changes Since v2:
>  - Rebased on top of Daniel Lezcano's Exynos cpuidle refactor patches.
>  - Removed early mapping of PMU base address from exynos.c and removed
>"get_exynos_pmuaddr" function. Instead of this added code in platsmp.c
>to get PMU base address using of_iomap as suggested by Tomasz Figa.
>  - Converted PMU implementation into platform_driver by using static
>platform_device method.
>
> Changes Since v1:
>  - Rebased on latest for-next of Kukjin Kim's tree.
>  - Updated patch: Add support for mapping PMU base address via DT
> - Removed __initdata from declaration of "exynos_pmu_base", as it 
> caused
> kernel crash as pointed out by Vikas Sajjan.
> - Added support for Syscon initialization and getting PMU regmap 
> handle
> as suggested by Sylwester. Since current implementation of early
> intialization [1] has limitation that "early_syscon_init" requires
> DT to be unflattened and system should be able to allocate memory,
> we can't use regmap handles for platsmp.c file as "smp_secondary_init"
> will be called before DT unflattening. So I have kept both method for
> accessing PMU base address. platsmp.c will use ioremmaped address 
> where
> as rest other files can use regmap handle.
>  - Updated patch: Refactored code for PMU register mapping via DT
> - Modified to use regmap_read/write when using regmap handle.
>  - Added patch: Add device tree based initialization support for PMU.
> - Convert existing PMU implementation to be a device tree based
>  before moving it to "drivers/mfd" folder. As suggested by Bartlomiej.
> - Dropped making a platform_driver for PMU, as currently PMU binding
> has two compatibility strings as "samsung, exynosxxx-pmu", "syscon",
> once we enable MFD_SYSCON config option, current "syscon" driver probe
> gets called and PMU probe never gets called. So modified PMU
> initialization code to scan DT and match against supported 
> compatiblity
> string in driver code, and once we get matching node use that for
> accessing PMU regmap handle using 
> "syscon_early_regmap_lookup_by_phandle".
> If there is any better solution please suggest.
>
>
> Pankaj Dubey (4):
>   ARM: EXYNOS: Add support for mapping PMU base address via DT
>   ARM: EXYNOS: Refactored code for using PMU address via DT
>   

Re: [PATCH 2/3] ARM: DTS: Add NTC thermistor nodes to Exynos5250 based Snow

[Naveen Krishna Ch]

Hello Doug and Kukjin,

On 26 June 2014 21:16, Doug Anderson  wrote:
> Naveen,
>
> On Thu, Jun 26, 2014 at 5:19 AM, Naveen Krishna Chatradhi
>  wrote:
>> Exynos5250 based Snow board has 4 NTC thermistors to measure
>> temperatures at various points on the board.
>>
>> IIO based ADC becomes the parent and NTC thermistors are the childs,
>> via the HWMON interface.
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> ---
>> Posted earlier by Doug Anderson @ https://lkml.org/lkml/2013/3/27/453
>>
>> This patch depends on (1/4 and 2/4 patches of) patchset posted
>> http://www.spinics.net/lists/linux-iio/msg13486.html
>> Which were applied on to Guenter Roeck's tree.
>>
>> cat sysfs entries exported by hwmon for 4 thermistors
>> and verified the values on Snow.
>>
>>  arch/arm/boot/dts/exynos5250-snow.dts |   34 
>> +
>>  1 file changed, 34 insertions(+)
>
> NAK.
>
> The first chunk of exynos5250-snow devices have the thermistors
> populated, but a huge chunk of devices also _don't_ have them
> populated.

I've realized only the rev4 and before boards have thermistors
while going through the git logs of snow related dts files
in an older chrome kernel.


>
> If I remember my history properly, rev3 and earlier all had
> thermistors.  Some of rev4 might have thermistors (I never got a clear
> answer).  ...and rev5 definitely doesn't have resistors.  Aside from
> thermistors there's no good reason to differentiate rev3 and rev4
> (they just have different memory).  The upstream kernel may eventually
> need to differentiate rev4 and rev5 since they have a different audio
> codec.

I've found one patch which says, "No thermistors on Rev5 and above boards"
I still thought, we should support few boards out there.

But, i din't knew they were removed completely.

>
> See  for some
> descriptions of the different revisions of snow and how they were
> handled in the Chrome OS tree.

Got it now, Thanks

>
> See  for
> thermistors talk.  Patch set #1 actually split out rev3, but we then
> decided that we really didn't need to use the thermistors on any of
> the revisions so the later patchsets just totally take them out.

So, no need of thermistor nodes on Snow.
I thought https://lkml.org/lkml/2013/3/27/453 patch is missed out.

>
> -Doug

Kukjin, Sorry for the confusion. Please drop this one.

-- 
Thanks,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] ARM: DTS: create common dtsi for Peach pit and pi boards

[Naveen Krishna Ch]

Hello Javier,

On 26 June 2014 20:51, Javier Martinez Canillas  wrote:
> Hello Naveen,
>
> On Thu, Jun 26, 2014 at 2:19 PM, Naveen Krishna Chatradhi
>  wrote:
>> This patchset does the following
>> 1. Create a common dtsi file cros-exynos-peach.dtsi for
>>exynos5420-peach-pit.dts and exynos5800-peach-pi.dts
>
> There was some previous discussion in this list about what's the best
> approach to handle common DTS chunks, please take a look to
> http://patchwork.ozlabs.org/patch/362633/.
>
> In summary, there is a common .dtsi file for Daisy based boards
> (arch/arm/boot/dts/exynos5250-cros-common.dtsi) but it seems it turned
> out to do more harm than good since having a single .dtsi for all the
> common DTS chunks is not quite flexible. As more boards gets
> introduced you have to start moving stuff from the common .dtsi file
> to the board .dts.
>
> The same was tried to do for OMAP2+ boards and it turned out that you
> need to either a) create a hierarchy of .dtsi files to model all the
> different board combinations that have similar fragments or b) split
> out isolated DTS fragments on an .dtsi and include a set of this
> fragments.
>
>  For an example of a) you can take a look to
> arch/arm/boot/dts/omap3-overo* and for b) to
> arch/arm/boot/dts/omap-gpmc-smsc9*.dtsi.
>
> For a Peach Pit/Pi specific example of b) you can look at the recent
> arch/arm/boot/dts/cros-ec-keyboard.dtsi file that Doug added for Peach
> Pit/Pi keyboard.

Right. It makes sense to have multiple smaller chunks
that can be included in more boards than having one big chunk
which can only be used for 2 or 3 boards.
But, then i was unsure. If Device Tree communities likes having more
smaller fragment files under one "arch/arm/boot/dts/ directory".


>
> Personally I think that b) is a more flexible and reusable approach.
> So, maybe instead of creating a cros-exynos-peach.dts to contain all
> the common DT nodes you can add a cros-ec-thermistor.dsti file that
> only includes the ADC based Thermistor nodes?

I've started with making a fragment dts naming it "cros-exynos-adc.dts".
Then moved on with an implementation similar to
exynos5250-cros-common.dtsi

>
> Thanks a lot and best regards,
> Javier

Will wait for few more opinions and make a fragment instead of common dtsi.
Thank you a lot for the information and the references.

>
>> 2. Adds the ADC based Thermistor nodes and enables them in peach_pit.dts
>>and peach_pi.dts
>> 3. Adds the ADC based Thermistor nodes for Exynos5250 based Snow
>> 4. Corrects the vendor prefix for thermistors in exynos4412-trats2.dts
>>
>> Naveen Krishna Chatradhi (3):
>>   ARM: DTS: use new compatible string for thermistors in trats2
>>   ARM: DTS: Add NTC thermistor nodes to Exynos5250 based Snow
>>   ARM: DTS: Add common dts file for Peach PIT and PI along with ADC
>> nodes
>>
>>  arch/arm/boot/dts/cros-exynos-peach.dtsi   |   41 
>> 
>>  arch/arm/boot/dts/exynos4412-trats2.dts|4 +--
>>  arch/arm/boot/dts/exynos5250-snow.dts  |   34 +++
>>  arch/arm/boot/dts/exynos5420-peach-pit.dts |6 
>>  arch/arm/boot/dts/exynos5800-peach-pi.dts  |6 
>>  5 files changed, 89 insertions(+), 2 deletions(-)
>>  create mode 100644 arch/arm/boot/dts/cros-exynos-peach.dtsi
>>
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 00/14] Add Maxim 77802 PMIC support

[Naveen Krishna Ch]

Hello Javier,

On 26 June 2014 00:33, Javier Martinez Canillas
 wrote:
> MAX77802 is a PMIC that contains 10 high efficiency Buck regulators,
> 32 Low-dropout (LDO) regulators, two 32kHz buffered clock outputs,
> a Real-Time-Clock (RTC) and a I2C interface to program the individual
> regulators, clocks and the RTC.
>
> This fourth version of the patch-set addresses several issues pointed
> out by Mark Brown, Doug Anderson and Krzysztof Kozlowski The individual
> changes are added on each patch change log.
>
> This series are based on drivers added by Simon Glass to the Chrome OS
> kernel and adds support for the Maxim 77802 Power Management IC, their
> regulators, clocks, RTC and I2C interface.
>
> NOTE: This version of the series model the real power scheme for Maxim
> 77802 regulators instead of a simplistic model like in older versions.
> So these changes depend on patch:
>
> "[PATCH v3] ARM: dts: Add cros_ec to exynos5420-peach-pit and 
> exynos5800-peach-pi"
> https://patchwork.kernel.org/patch/4411351/
>
> which adds tps65090 support to Peach boards since regulators from this
> PMIC supply power to a set of MAX77802 regulators.
>
> The patch-set has been tested on both Daisy/Snow (max77686) and Peach
> pit (max77802) Chromebooks and it's composed of the following patches:
>
> Doug Anderson (1):
>   mfd: max77686: Allow the max77686 rtc to wakeup the system
>
> Javier Martinez Canillas (13):
>   mfd: max77686: Convert to use regmap_irq
>   clk: max77686: Add DT include for MAX77686 PMIC clock
>   clk: max77686: Improve Maxim 77686 PMIC clocks binding
>   clk: Add generic driver for Maxim PMIC clocks
>   clk: max77686: Convert to the generic max clock driver
>   mfd: Add driver for Maxim 77802 Power Management IC
>   mfd: max77802: Add DT binding documentation
>   regmap: Add regmap_reg_copy function
>   regulator: Add driver for Maxim 77802 PMIC regulators
>   clk: Add driver for Maxim 77802 PMIC clocks
>   clk: max77802: Add DT binding documentation
>   rtc: Add driver for Maxim 77802 PMIC Real-Time-Clock
>   ARM: dts: Add max77802 to exynos5420-peach-pit and exynos5800-peach-pi
>
>  .../devicetree/bindings/clock/maxim,max77686.txt   |  15 +-
>  .../devicetree/bindings/clock/maxim,max77802.txt   |  42 ++
>  Documentation/devicetree/bindings/mfd/max77802.txt |  97 +++
>  arch/arm/boot/dts/exynos5420-peach-pit.dts | 343 ++
>  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 343 ++
>  drivers/base/regmap/regmap.c   |  34 +
>  drivers/clk/Kconfig|  11 +
>  drivers/clk/Makefile   |   2 +
>  drivers/clk/clk-max-gen.c  | 195 ++
>  drivers/clk/clk-max-gen.h  |  32 +
>  drivers/clk/clk-max77686.c | 183 +-
>  drivers/clk/clk-max77802.c |  99 +++
>  drivers/mfd/Kconfig|  15 +
>  drivers/mfd/Makefile   |   3 +-
>  drivers/mfd/max77686-irq.c | 319 --
>  drivers/mfd/max77686.c |  97 ++-
>  drivers/mfd/max77802.c | 366 +++
>  drivers/regulator/Kconfig  |   9 +
>  drivers/regulator/Makefile |   1 +
>  drivers/regulator/max77802.c   | 694 
> +
>  drivers/rtc/Kconfig|  10 +
>  drivers/rtc/Makefile   |   1 +
>  drivers/rtc/rtc-max77686.c |  55 +-
>  drivers/rtc/rtc-max77802.c | 637 +++
>  include/dt-bindings/clock/maxim,max77686.h |  23 +
>  include/dt-bindings/clock/maxim,max77802.h |  22 +
>  include/linux/mfd/max77686-private.h   |  28 +-
>  include/linux/mfd/max77686.h   |   2 -
>  include/linux/mfd/max77802-private.h   | 307 +
>  include/linux/mfd/max77802.h   | 121 
>  include/linux/regmap.h |   9 +
>  31 files changed, 3583 insertions(+), 532 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/clock/maxim,max77802.txt
>  create mode 100644 Documentation/devicetree/bindings/mfd/max77802.txt
>  create mode 100644 drivers/clk/clk-max-gen.c
>  create mode 100644 drivers/clk/clk-max-gen.h
>  create mode 100644 drivers/clk/clk-max77802.c
>  delete mode 100644 drivers/mfd/max77686-irq.c
>  create mode 100644 drivers/mfd/max77802.c
>  create mode 100644 drivers/regulator/max77802.c
>  create mode 100644 drivers/rtc/rtc-max77802.c
>  create mode 100644 include/dt-bindings/clock/maxim,max77686.h
>  create mode 100644 include/dt-bindings/clock/maxim,max77802.h
>  create mode 100644 include/linux/mfd/max77802-private.h
>  create mode 100644 include/linux/mfd/max77802.h
>
> --
> 2.0.0.rc2
> --
> To unsubscribe from this l

Re: [PATCH 2/2] i2c: exynos5: fix minor styling nits

[Naveen Krishna Ch]

Hello Sachin,

On 25 June 2014 16:19, Sachin Kamat  wrote:
> Hi Naveen,
>
> On Wed, Jun 25, 2014 at 4:08 PM, Naveen Krishna Chatradhi
>  wrote:
>> This patch removes an extra line and fixes a styling nit
>> in exynos5_i2c_message_start()
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> ---
>>  drivers/i2c/busses/i2c-exynos5.c |3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-exynos5.c 
>> b/drivers/i2c/busses/i2c-exynos5.c
>> index 0d1a7bc..4c2e6f3 100644
>> --- a/drivers/i2c/busses/i2c-exynos5.c
>> +++ b/drivers/i2c/busses/i2c-exynos5.c
>> @@ -525,7 +525,7 @@ static void exynos5_i2c_message_start(struct exynos5_i2c 
>> *i2c, int stop)
>> if (i2c->msg->flags & I2C_M_RD) {
>> i2c_ctl |= HSI2C_RXCHON;
>>
>> -   i2c_auto_conf = HSI2C_READ_WRITE;
>> +   i2c_auto_conf |= HSI2C_READ_WRITE;
>
> This change looks more than just a styling nit. Please update the commit 
> message
> accordingly.

Yea, change looks so.

But, This is not an going to change the way code works.

As, i2c_auto_conf is initialized to '0' at the beginning of the function
and  HSI2C_READ_WRITE is defined as (1u << 16)

This being the 1st usage, I thought using "|=" is better way of assignment.

Will edit the commit message accordingly.

>
> --
> Regards,
> Sachin.

Thanks,



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv4 2/4] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC

[Naveen Krishna Ch]

Hello Tomasz,

On 20 June 2014 06:00, Tomasz Figa  wrote:
> On 20.06.2014 02:28, Chanwoo Choi wrote:
>> On 06/20/2014 09:24 AM, Tomasz Figa wrote:
>>> On 20.06.2014 02:22, Chanwoo Choi wrote:
 Hi Tomasz,

 On 06/18/2014 04:58 PM, Tomasz Figa wrote:
> Hi Chanwoo,
>
> On 18.06.2014 04:20, Chanwoo Choi wrote:
>> This patch control special clock for ADC in Exynos series's FSYS block.
>> If special clock of ADC is registerd on clock list of common clk 
>> framework,
>> Exynos ADC drvier have to control this clock.
>>
>> Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
>> - 'adc' clock: bus clock for ADC
>>
>> Exynos3250 has additional 'sclk_adc' clock as following:
>> - 'sclk_adc' clock: special clock for ADC which provide clock to 
>> internal ADC
>>
>> Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_adc' 
>> clock
>> in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included 
>> 'sclk_adc'
>> clock in FSYS_BLK.
>>
>> Signed-off-by: Chanwoo Choi 
>> Acked-by: Kyungmin Park 
>> ---
>>  drivers/iio/adc/exynos_adc.c | 93 
>> ++--
>>  1 file changed, 81 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
>> index c30def6..6b026ac 100644
>> --- a/drivers/iio/adc/exynos_adc.c
>> +++ b/drivers/iio/adc/exynos_adc.c
>> @@ -41,7 +41,8 @@
>>
>>  enum adc_version {
>>   ADC_V1,
>> - ADC_V2
>> + ADC_V2,
>> + ADC_V2_EXYNOS3250,
>>  };
>>
>>  /* EXYNOS4412/5250 ADC_V1 registers definitions */
>> @@ -85,9 +86,11 @@ enum adc_version {
>>  #define EXYNOS_ADC_TIMEOUT   (msecs_to_jiffies(100))
>>
>>  struct exynos_adc {
>> + struct device   *dev;
>>   void __iomem*regs;
>>   void __iomem*enable_reg;
>>   struct clk  *clk;
>> + struct clk  *sclk;
>>   unsigned intirq;
>>   struct regulator*vdd;
>>   struct exynos_adc_ops   *ops;
>> @@ -96,6 +99,7 @@ struct exynos_adc {
>>
>>   u32 value;
>>   unsigned intversion;
>> + boolneeds_sclk;
>
> This should be rather a part of the variant struct. See my comments to
> patch 1/4.

 OK, I'll include 'needs_sclk' in "variant" structure.

>
>>  };
>>
>>  struct exynos_adc_ops {
>> @@ -103,11 +107,21 @@ struct exynos_adc_ops {
>>   void (*clear_irq)(struct exynos_adc *info);
>>   void (*start_conv)(struct exynos_adc *info, unsigned long addr);
>>   void (*stop_conv)(struct exynos_adc *info);
>> + void (*disable_clk)(struct exynos_adc *info);
>> + int (*enable_clk)(struct exynos_adc *info);
>>  };
>>
>>  static const struct of_device_id exynos_adc_match[] = {
>> - { .compatible = "samsung,exynos-adc-v1", .data = (void *)ADC_V1 },
>> - { .compatible = "samsung,exynos-adc-v2", .data = (void *)ADC_V2 },
>> + {
>> + .compatible = "samsung,exynos-adc-v1",
>> + .data = (void *)ADC_V1,
>> + }, {
>> + .compatible = "samsung,exynos-adc-v2",
>> + .data = (void *)ADC_V2,
>> + }, {
>> + .compatible = "samsung,exynos3250-adc-v2",
>> + .data = (void *)ADC_V2_EXYNOS3250,
>> + },
>>   {},
>>  };
>>  MODULE_DEVICE_TABLE(of, exynos_adc_match);
>> @@ -156,11 +170,42 @@ static void exynos_adc_v1_stop_conv(struct 
>> exynos_adc *info)
>>   writel(con, ADC_V1_CON(info->regs));
>>  }
>>
>> +static void exynos_adc_disable_clk(struct exynos_adc *info)
>> +{
>> + if (info->needs_sclk)
>> + clk_disable_unprepare(info->sclk);
>> + clk_disable_unprepare(info->clk);
>> +}
>> +
>> +static int exynos_adc_enable_clk(struct exynos_adc *info)
>> +{
>> + int ret;
>> +
>> + ret = clk_prepare_enable(info->clk);
>> + if (ret) {
>> + dev_err(info->dev, "failed enabling adc clock: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + if (info->needs_sclk) {
>> + ret = clk_prepare_enable(info->sclk);
>> + if (ret) {
>> + clk_disable_unprepare(info->clk);
>> + dev_err(info->dev,
>> + "failed enabling sclk_tsadc clock: %d\n", ret);
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>>  static struct exynos_adc_ops exynos_adc_v1_ops = {
>>   .init_hw= exynos_adc_v1_init_hw,
>>   .clear_irq  = exynos_adc_v1_clear_irq,
>>   .start_conv = exynos_adc_v1_start_conv,
>>   .stop_conv  = exynos_adc_v1_stop_conv,
>> + .disable_clk= exynos_adc_disable_clk,
>> + .enable_clk = exynos_adc_enabl

Re: [PATCHv4 3/4] iio: devicetree: Add DT binding documentation for Exynos3250 ADC

[Naveen Krishna Ch]

Hello Chanwoo,

On 18 June 2014 07:51, Chanwoo Choi  wrote:
> This patch add DT binding documentation for Exynos3250 ADC IP. Exynos3250 has
> special clock ('sclk_tsadc') for ADC which provide clock to internal ADC.
>
> Signed-off-by: Chanwoo Choi 
> Acked-by: Kyungmin Park 

Changes look good to me.
Reviewed-by: Naveen Krishna Chatradhi 

> ---
>  .../devicetree/bindings/arm/samsung/exynos-adc.txt   | 20 
> 
>  1 file changed, 20 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt 
> b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> index 5d49f2b..3a5af82 100644
> --- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> @@ -14,6 +14,8 @@ Required properties:
> for exynos4412/5250 controllers.
> Must be "samsung,exynos-adc-v2" for
> future controllers.
> +   Must be "samsung,exynos3250-adc-v2" for
> +   for exynos3250 controllers.
>  - reg: Contains ADC register address range (base address and
> length) and the address of the phy enable register.
>  - interrupts:  Contains the interrupt information for the timer. The
> @@ -21,7 +23,11 @@ Required properties:
> the Samsung device uses.
>  - #io-channel-cells = <1>; As ADC has multiple outputs
>  - clocks   From common clock binding: handle to adc clock.
> +   From common clock binding: handle to sclk_tsadc clock
> +   if using Exynos3250.
>  - clock-names  From common clock binding: Shall be "adc".
> +   From common clock binding: Shall be "sclk_tsadc"
> +   if using Exynos3250.
>  - vdd-supply   VDD input supply.
>
>  Note: child nodes can be added for auto probing from device tree.
> @@ -41,6 +47,20 @@ adc: adc@12D1 {
> vdd-supply = <&buck5_reg>;
>  };
>
> +Example: adding device info in dtsi file for Exynos3250 with additional sclk
> +
> +adc: adc@126C {
> +   compatible = "samsung,exynos3250-adc-v2";
> +   reg = <0x126C 0x100>, <0x10020718 0x4>;
> +   interrupts = <0 137 0>;
> +   #io-channel-cells = <1>;
> +   io-channel-ranges;
> +
> +   clocks = <&cmu CLK_TSADC>, <&cmu CLK_SCLK_TSADC>;
> +   clock-names = "adc", "sclk_adc";
> +
> +   vdd-supply = <&buck5_reg>;
> +};
>
>  Example: Adding child nodes in dts file
>
> --
> 1.8.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv4 1/4] iio: adc: exynos_adc: Add exynos_adc_ops structure to improve readability

[Naveen Krishna Ch]

Hello Chanwoo,

On 18 June 2014 07:50, Chanwoo Choi  wrote:
> This patchset add 'exynos_adc_ops' structure which includes some functions
> to control ADC operation according to ADC version (v1 or v2).
>
> Signed-off-by: Chanwoo Choi 
> Acked-by: Kyungmin Park 

This is a good piece of change, Thanks.

Reviewed-by: Naveen Krishna Chatradhi 
> ---
>  drivers/iio/adc/exynos_adc.c | 174 
> +--
>  1 file changed, 120 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
> index 010578f..c30def6 100644
> --- a/drivers/iio/adc/exynos_adc.c
> +++ b/drivers/iio/adc/exynos_adc.c
> @@ -90,6 +90,7 @@ struct exynos_adc {
> struct clk  *clk;
> unsigned intirq;
> struct regulator*vdd;
> +   struct exynos_adc_ops   *ops;
>
> struct completion   completion;
>
> @@ -97,6 +98,13 @@ struct exynos_adc {
> unsigned intversion;
>  };
>
> +struct exynos_adc_ops {
> +   void (*init_hw)(struct exynos_adc *info);
> +   void (*clear_irq)(struct exynos_adc *info);
> +   void (*start_conv)(struct exynos_adc *info, unsigned long addr);
> +   void (*stop_conv)(struct exynos_adc *info);
> +};
> +
>  static const struct of_device_id exynos_adc_match[] = {
> { .compatible = "samsung,exynos-adc-v1", .data = (void *)ADC_V1 },
> { .compatible = "samsung,exynos-adc-v2", .data = (void *)ADC_V2 },
> @@ -112,30 +120,98 @@ static inline unsigned int 
> exynos_adc_get_version(struct platform_device *pdev)
> return (unsigned int)match->data;
>  }
>
> -static void exynos_adc_hw_init(struct exynos_adc *info)
> +static void exynos_adc_v1_init_hw(struct exynos_adc *info)
> +{
> +   u32 con1;
> +
> +   /* set default prescaler values and Enable prescaler */
> +   con1 =  ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
> +
> +   /* Enable 12-bit ADC resolution */
> +   con1 |= ADC_V1_CON_RES;
> +   writel(con1, ADC_V1_CON(info->regs));
> +}
> +
> +static void exynos_adc_v1_start_conv(struct exynos_adc *info, unsigned long 
> addr)
> +{
> +   u32 con1;
> +
> +   writel(addr, ADC_V1_MUX(info->regs));
> +
> +   con1 = readl(ADC_V1_CON(info->regs));
> +   writel(con1 | ADC_CON_EN_START, ADC_V1_CON(info->regs));
> +}
> +
> +static void exynos_adc_v1_clear_irq(struct exynos_adc *info)
> +{
> +   writel(1, ADC_V1_INTCLR(info->regs));
> +}
> +
> +static void exynos_adc_v1_stop_conv(struct exynos_adc *info)
> +{
> +   u32 con;
> +
> +   con = readl(ADC_V1_CON(info->regs));
> +   con |= ADC_V1_CON_STANDBY;
> +   writel(con, ADC_V1_CON(info->regs));
> +}
> +
> +static struct exynos_adc_ops exynos_adc_v1_ops = {
> +   .init_hw= exynos_adc_v1_init_hw,
> +   .clear_irq  = exynos_adc_v1_clear_irq,
> +   .start_conv = exynos_adc_v1_start_conv,
> +   .stop_conv  = exynos_adc_v1_stop_conv,
> +};
> +
> +static void exynos_adc_v2_init_hw(struct exynos_adc *info)
>  {
> u32 con1, con2;
>
> -   if (info->version == ADC_V2) {
> -   con1 = ADC_V2_CON1_SOFT_RESET;
> -   writel(con1, ADC_V2_CON1(info->regs));
> +   con1 = ADC_V2_CON1_SOFT_RESET;
> +   writel(con1, ADC_V2_CON1(info->regs));
>
> -   con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
> -   ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
> -   writel(con2, ADC_V2_CON2(info->regs));
> +   con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
> +   ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
> +   writel(con2, ADC_V2_CON2(info->regs));
>
> -   /* Enable interrupts */
> -   writel(1, ADC_V2_INT_EN(info->regs));
> -   } else {
> -   /* set default prescaler values and Enable prescaler */
> -   con1 =  ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
> +   /* Enable interrupts */
> +   writel(1, ADC_V2_INT_EN(info->regs));
> +}
>
> -   /* Enable 12-bit ADC resolution */
> -   con1 |= ADC_V1_CON_RES;
> -   writel(con1, ADC_V1_CON(info->regs));
> -   }
> +static void exynos_adc_v2_start_conv(struct exynos_adc *info, unsigned long 
> addr)
> +{
> +   u32 con1, con2;
> +
> +   con2 = readl(ADC_V2_CON2(info->regs));
> +   con2 &= ~ADC_V2_CON2_ACH_MASK;
> +   con2 |= ADC_V2_CON2_ACH_SEL(addr);
> +   writel(con2, ADC_V2_CON2(info->regs));
> +
> +   con1 = readl(ADC_V2_CON1(info->regs));
> +   writel(con1 | ADC_CON_EN_START, ADC_V2_CON1(info->regs));
> +}
> +
> +static void exynos_adc_v2_clear_irq(struct exynos_adc *info)
> +{
> +   writel(1, ADC_V2_INT_ST(info->regs));
> +}
> +
> +static void exynos_adc_v2_stop_conv(struct exynos_adc *info)
> +{
> +   u32 con;
> +
> +   con = readl(ADC_V2_CON1(info->regs));
> +   con &= ~ADC_CON_EN_START;
> +   writel(con, ADC_V2_CON1(info->regs));
>  }
>
> +sta

Re: [PATCH] i2c: exynos5: Initialise Samsung High Speed I2C controller early

[Naveen Krishna Ch]

Hello Wolfram,

On 21 May 2014 15:55, Wolfram Sang  wrote:
> On Fri, May 09, 2014 at 03:54:25PM +0100, Mark Brown wrote:
>> On Fri, May 09, 2014 at 08:12:47PM +0530, Naveen Krishna Ch wrote:
>> > On 9 May 2014 19:21, Mark Brown  wrote:
>> > > On Fri, May 09, 2014 at 05:50:00PM +0530, Naveen Krishna Ch wrote:
>>
>> > >> DRM related drivers like DP, FIMD, HDMI, Mixer wants to be probed ASAP
>> > >> during the boot.
>> > >> The real problem comes when, one of these drivers do a regulator_get().
>>
>> > >> If the physical supply  is not enabled/hookedup the regulator_get() call
>> > >> assumes that physical supply is present and returns a
>> > >> "dummy_regulator" (But, not an error).
>>
>> > >> Because of which, Display and several other devices fails to work.
>>
>> > > These drivers are buggy, if they geniunely expect and handle a missing
>> > > supply then they should be using regulator_get_optional() to request the
>> > > regulator and even if they don't the use of subsys_initcall() is not
>> > > going to fix anything here - if a dummy regulator is going to be
>> > > returned the time things are probed won't make a difference.
>>
>> ...
>>
>> > If all the I2C, SPI, DMA, I2C_TUNNEL, DRM based LCD are all mod_probes()
>> > DRM drivers are probing a head of the PMIC probe. Which is causing the
>> > display drivers to get "dummy_regulators" instead of the real supplies.
>>
>> No, it really won't - I have no idea what you are doing but it's not
>> mainline.  If you are getting dummy regulators then you don't have a
>> supply present at all and probe ordering isn't going to make a blind
>> bit of difference.
>>
>> Please provide a specific technical description of the problem you are
>> seeing in mainline.
>
> +1 Unless we have a clear understanding that this is the only acceptable
> solution in mainline, this is really an out-of-tree patch.

Few of the DRM based devices need regulators during their probe and
DRM subsystem
wants to bring up LCD as fast as it could to give a better user experience.

Exynos DRM (few others for that matter) does platform_driver_register()
of devices in a sequence and finally binds them all together into one
blob or /dev/dri-0 device.
Which makes it hard to implement -EPROBE_DEFER. Even if -EPROBE_DEFER is
implemented in DRM, it adds lot of overhead during the boot up.

I've proposed to make exynos_drm_init() as late_initcall() instead of making
I2C, SPI, DMA and I2C-arbitrator and I2C-TUNNEL drivers as subsys_initcall()

http://www.spinics.net/lists/linux-samsung-soc/msg30858.html

Kindly, suggest a workable approach for all the subsystems.
>

-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i2c: exynos5: add support for HSI2C on Exynos5260 SoC

[Naveen Krishna Ch]

Hello Wolfram,

On 21 May 2014 16:04, Wolfram Sang  wrote:
> On Mon, Apr 28, 2014 at 02:29:58PM +0530, Naveen Krishna Chatradhi wrote:
>> HSI2C module on Exynos5260 differs from current modules in
>> following ways:
>> 1.  HSI2C on Exynos5260 has fifo_depth of 16bytes
>> 2.  Module needs to be reset as a part of init sequence.
>>
>> Hence, Following changes are involved.
>> 1. Add a new compatible string and Updates the Documentation dt bindings.
>> 2. Introduce a variant struct to support the changes in H/W
>> 3. Reset the module during init. Thus, bringing the module back
>> to default state irrespective of what firmware did with it.
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
I just realized another typo. Its my email id:  ch.nav...@samsung.com

>> Signed-off-by: Pankaj Dubey 
>> ---
>
> ...
>
>> - fifo_ctl |= HSI2C_RXFIFO_TRIGGER_LEVEL(HSI2C_DEF_TXFIFO_LVL);
>> + trig_lvl = (i2c->msg->len > i2c->variant->fifo_depth) ?
>> + (i2c->variant->fifo_depth * 3/4) : i2c->msg->len;
>> + fifo_ctl |= HSI2C_RXFIFO_TRIGGER_LEVEL(trig_lvl);
>> +
>
> Dunno why checkpatch missed the 'space around operator' issue, yet I
> fixed it here...
>
> Applied to for-next, thanks!
You want me to send another version fixing these nits ?
>



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i2c: exynos5: Initialise Samsung High Speed I2C controller early

[Naveen Krishna Ch]

Hello Mark,

On 9 May 2014 19:21, Mark Brown  wrote:
> On Fri, May 09, 2014 at 05:50:00PM +0530, Naveen Krishna Ch wrote:
>> On 24 April 2014 21:55, Mark Brown  wrote:
>
>> >> Such solution has been proposed by Mark Brown to fix the problem of
>> >> the regulators not beeing available on the peripheral device probe():
>> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2010-March/011971.html
>
>> > What specifically is this needed for?  We *should* be able to use
>> > deferred probe for most things, but I know that not all subsystems are
>> > able to yet.
>
>> DRM related drivers like DP, FIMD, HDMI, Mixer wants to be probed ASAP
>> during the boot.
>> The real problem comes when, one of these drivers do a regulator_get().
>
>> If the physical supply  is not enabled/hookedup the regulator_get() call
>> assumes that physical supply is present and returns a
>> "dummy_regulator" (But, not an error).
>
>> Because of which, Display and several other devices fails to work.
>
> These drivers are buggy, if they geniunely expect and handle a missing
> supply then they should be using regulator_get_optional() to request the
> regulator and even if they don't the use of subsys_initcall() is not
> going to fix anything here - if a dummy regulator is going to be
> returned the time things are probed won't make a difference.
We have a situation where.a PMIC is sitting under I2C_TUNNEL
with I2C, SPI and SPI uses DMA.

PMIC --- I2C_TUNNEL  I2C/SPI  DMA

This PMIC is setting some FETS required for Backlight, LCD and G3D modules.

If all the I2C, SPI, DMA, I2C_TUNNEL, DRM based LCD are all mod_probes()
DRM drivers are probing a head of the PMIC probe. Which is causing the
display drivers to get "dummy_regulators" instead of the real supplies.

We couldn't implement -PROBE_DEFER because, the probes are not failing.

Should we should check if the return value of regulator_get() is a
"dummy_regulator"
and then defer the probe /.

>
>> I2C, I2C_TUNNEL, SPI and DMA drivers are required as subsys_initcall()
>> for similar reason.
>
> What makes you say this?  Typically those drivers don't use regulators
> at all.
I mean I2C, I2C_TUNNEL, SPI and DMA drivers have be to subsys_initcall()
to get the PMIC up intime. so, that the system would use the real supplies.

This looks like a board specific solution. I guess, this is quite
frequent with the
buses like I2C, SPI.

Kindly, suggest a nicer way. Thanks



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i2c: exynos5: Initialise Samsung High Speed I2C controller early

[Naveen Krishna Ch]

Hello Mark,

On 24 April 2014 21:55, Mark Brown  wrote:
> On Thu, Apr 24, 2014 at 08:18:36PM +0530, Naveen Krishna Chatradhi wrote:
>> This patch moves initialization code to subsys_initcall() to ensure
>> that the i2c bus is available early so the regulators can be quickly
>> probed and available for other devices on their probe() call.
>
>> Such solution has been proposed by Mark Brown to fix the problem of
>> the regulators not beeing available on the peripheral device probe():
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2010-March/011971.html
>
> What specifically is this needed for?  We *should* be able to use
> deferred probe for most things, but I know that not all subsystems are
> able to yet.
DRM related drivers like DP, FIMD, HDMI, Mixer wants to be probed ASAP
during the boot.
The real problem comes when, one of these drivers do a regulator_get().

If the physical supply  is not enabled/hookedup the regulator_get() call
assumes that physical supply is present and returns a
"dummy_regulator" (But, not an error).

Because of which, Display and several other devices fails to work.

I2C, I2C_TUNNEL, SPI and DMA drivers are required as subsys_initcall()
for similar reason.

-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/7 v8] crypto:s5p-sss: Add Device tree and Exynos support

[Naveen Krishna Ch]

Hello Herbert,

On 30 April 2014 17:44, Herbert Xu  wrote:
> On Wed, Apr 30, 2014 at 04:38:05PM +0530, Naveen Krishna Ch wrote:
>> Hello All,
>>
>> On 28 April 2014 16:14, Naveen Krishna Chatradhi  
>> wrote:
>> > SSS module on Exynos4210, Exynos5250 and Exynos5420 SoCs has added
>> > features to the one on S5PV210. However with minor changes the s5p-sss.c
>> > driver can be reused to support SSS modules on Exynos4 and 5 SoCs.
>> >
>> > This patch set
>> > 1. Adds device tree support to the s5p-sss.c driver and Documentation
>> > 2. Adds code to support SSS module on Exynos4 and 5 SoCs
>> > 3. Adds variant struct to handle the differences in SSS modules
>> > 4. Adds clk_prepare/clk_unprepare clocks to the s5p-sss.c driver
>> >
>> > Note: Compatible "exynos4210-secss" should work for Exynos4412 and
>> >   Exynos5260 (Exynos5260, for which ARCH code is under review)
>> > I couldn't test on Exynos4412 and Exynos4210 boards, Should be able to
>> > test with addition of DT node and clocks support.
>> >
>> > These patches are under review at
>> > https://lkml.org/lkml/2014/2/17/124
>> >
>> > Naveen Krishna Chatradhi (7):
>> >   crypto:s5p-sss: Use platform_get_irq() instead of _byname()
>> >   crypto:s5p-sss: Kconfig: Let Exynos SoCs select SSS driver
>> >   crypto:s5p-sss: Look for the next request in the queue
>> >   crypto:s5p-sss: Add device tree support
>> >   crypto:s5p-sss: Add support for SSS module on Exynos
>> >   crypto:s5p-sss: validate iv before memcpy
>> >   crypto:s5p-sss: Use clk_prepare/clk_unprepare
>> >
>> >  .../devicetree/bindings/crypto/samsung-sss.txt |   35 +
>> >  drivers/crypto/Kconfig |6 +-
>> >  drivers/crypto/s5p-sss.c   |  145 
>> > +++-
>> >  3 files changed, 150 insertions(+), 36 deletions(-)
>> >  create mode 100644 
>> > Documentation/devicetree/bindings/crypto/samsung-sss.txt
>>
>> Can we get this series merged in.
>> Its has got reviewed and re-based several times and got acked by a
>> couple of seniors.
>
> Do you wa1nt me to pick these series up?
Yes please.
>
> Cheers,
Thanks,
Naveen
> --
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/7 v8] crypto:s5p-sss: Add Device tree and Exynos support

[Naveen Krishna Ch]

Hello All,

On 28 April 2014 16:14, Naveen Krishna Chatradhi  wrote:
> SSS module on Exynos4210, Exynos5250 and Exynos5420 SoCs has added
> features to the one on S5PV210. However with minor changes the s5p-sss.c
> driver can be reused to support SSS modules on Exynos4 and 5 SoCs.
>
> This patch set
> 1. Adds device tree support to the s5p-sss.c driver and Documentation
> 2. Adds code to support SSS module on Exynos4 and 5 SoCs
> 3. Adds variant struct to handle the differences in SSS modules
> 4. Adds clk_prepare/clk_unprepare clocks to the s5p-sss.c driver
>
> Note: Compatible "exynos4210-secss" should work for Exynos4412 and
>   Exynos5260 (Exynos5260, for which ARCH code is under review)
> I couldn't test on Exynos4412 and Exynos4210 boards, Should be able to
> test with addition of DT node and clocks support.
>
> These patches are under review at
> https://lkml.org/lkml/2014/2/17/124
>
> Naveen Krishna Chatradhi (7):
>   crypto:s5p-sss: Use platform_get_irq() instead of _byname()
>   crypto:s5p-sss: Kconfig: Let Exynos SoCs select SSS driver
>   crypto:s5p-sss: Look for the next request in the queue
>   crypto:s5p-sss: Add device tree support
>   crypto:s5p-sss: Add support for SSS module on Exynos
>   crypto:s5p-sss: validate iv before memcpy
>   crypto:s5p-sss: Use clk_prepare/clk_unprepare
>
>  .../devicetree/bindings/crypto/samsung-sss.txt |   35 +
>  drivers/crypto/Kconfig |6 +-
>  drivers/crypto/s5p-sss.c   |  145 
> +++-
>  3 files changed, 150 insertions(+), 36 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/crypto/samsung-sss.txt

Can we get this series merged in.
Its has got reviewed and re-based several times and got acked by a
couple of seniors.

Thanks,
>
> --
> 1.7.9.5
>



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2 v4] i2c: exynos5: add support for HSI2C on Exynos5260 SoC

[Naveen Krishna Ch]

Hello Wolfram,

On 13 March 2014 00:48, Wolfram Sang  wrote:
> On Fri, Feb 07, 2014 at 10:12:51AM +0530, Naveen Krishna Chatradhi wrote:
>> This patch adds a new compatible and uses variant struct to support
>> HSI2C module on Exynos5260. Updates the Documentation dt bindings.
>> Also resets the module as an init sequence (Needed by Exynos5260).
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>
> This patch has clearly not been tested :( Build failure!
comma was missing, Not sure, how i missed it.
Will fix it.
>
>> +struct exynos_hsi2c_variant {
>> + unsigned intfifo_depth;
>> +};
>
> Why so many tabs? In general, I'd prefer one space.
>
>> - exynos5_i2c_init(i2c);
>> + exynos5_i2c_reset(i2c);
>
> Is this a related change?
Exynos5260 needs the HSI2C module to be reset during the init.
As per Tomasz's comment on earlier version. We will reset the status
during init for every SoC.
>



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2 v4] i2c: exynos5: configure fifo_depth based on HSI2C module variant

[Naveen Krishna Ch]

Hello Wolfram,

On 13 March 2014 00:50, Wolfram Sang  wrote:
> On Fri, Feb 07, 2014 at 10:13:15AM +0530, Naveen Krishna Chatradhi wrote:
>> fifo_depth of the HSI2C is not constant
>> Exynos5420 and Exynos5250 supports fifo_depth of 64bytes
>> Exynos5260 supports fifo_depth of 16bytes.
>>
>> This patch configures the fifo_depth based on HSI2C modules version.
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> [For finding out the difference and initial contribution]
>> Signed-off-by: Pankaj Dubey 
>
> I know Tomasz said differently, but I prefer the patches squashed (and
> the commit message extended).
Please accept my apologies for coming back late on this CL.
Will squash and fix the compilation error and submit.

Thanks,
>



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] iio: exynos_adc: use indio_dev->dev structure to handle child nodes

[Naveen Krishna Ch]

Hello Jonathan,

On 26 April 2014 18:23, Jonathan Cameron  wrote:
> On 25/04/14 16:46, Doug Anderson wrote:
>>
>> Naveen,
>>
>> Thanks for sending this.  Given that Jonathan Cameron was involved in
>> the previous discussion, it probably would have been wise to include
>> him on the CC list.
>
> In my case, don't worry too much as I have linux-iio coming into exactly
> the same place in my inbox. Doug is correct that it is generally a good
> idea unless someone has asked you not to.
Sure, will make it a habit.
>
>>
>> On Fri, Apr 25, 2014 at 3:14 AM, Naveen Krishna Chatradhi
>>  wrote:
>>>
>>> From: Naveen Krishna Ch 
>>>
>>> Using pdev->dev with device_for_each_child() would iterate over all
>>> of the children of the platform device and delete them.
>>> Thus, causing crashes during module unload.
>>>
>>> We should be using the indio_dev->dev structure for
>>> registering/unregistering child nodes.
>>>
>>> Signed-off-by: Naveen Krishna Ch 
>>> ---
>>> This change was tested on top of
>>> https://lkml.org/lkml/2014/4/21/481 from Doug.
>>>
>>>   drivers/iio/adc/exynos_adc.c |6 +++---
>>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>
>>
>> Reported-by: Doug Anderson 
>> Reviewed-by: Doug Anderson 
>> Tested-by: Doug Anderson 
>
> Applied to the fixes-togreg branch of iio.git
I've submitted the v2.
Kindly, review the other 4 patches in this series.
Thanks
>
> Thanks.
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v11 0/4] thermal: samsung: Clean up and add support for Exynos5420

[Naveen Krishna Ch]

Hello Tomasz,

On 20 March 2014 00:58, Tomasz Figa  wrote:
> Hi Leela,
>
>
> On 19.03.2014 12:19, Leela Krishna Amudala wrote:
>>
>> Hi All,
>>
>> I didn't see this series in mainline, Any comments for this ?
>
>
> Naveen had posted v12 of this series and I believe all the patches got my
> Reviewed-by.
>
> Best regards,
> Tomasz
Thanks for your reply.
These patches are posted to the mailing list quite some time now.
Anything i can do to speed up the process.




-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9 v7] crypto:s5p-sss: Add DT and Exynos support

[Naveen Krishna Ch]

Hello Everyone,

On 25 February 2014 15:16, Herbert Xu  wrote:
> On Mon, Feb 17, 2014 at 03:14:26PM +0530, Naveen Krishna Chatradhi wrote:
>> SSS module on Exynos4210, Exynos5250 and Exynos5420 SoCs has added
>> features to the one on S5PV210. However with minor changes the s5p-sss.c
>> driver can be reused to support SSS modules on Exynos4 and 5 SoCs.
>>
>> This patch set
>> 1. Adds device tree support to the s5p-sss.c driver and Documentation
>> 2. Adds code to support SSS module on Exynos4 and 5 SoCs
>> 3. Adds device tree node to Exynos5250 and Exynos5420
>> 4. Adds variant struct to handle the differences in SSS modules
>> 5. Adds clk_prepare/clk_unprepare clocks to the s5p-sss.c driver
>>
>> Note: Compatible "exynos4210-secss" should work for Exynos4412 and
>>   Exynos5260 (Exynos5260, for which ARCH code is under review)
>> I couldn't test on Exynos4412 and Exynos4210 boards, Should be able to
>> test with addition of DT node and clocks support.
>>
>> Naveen Krishna Ch (7): [crypto-2.6.git]
>>   crypto:s5p-sss: Use platform_get_irq() instead of _byname()
>>   crypto:s5p-sss: Kconfig: Let Exynos SoCs select SSS driver
>>   crypto:s5p-sss: Look for the next request in the queue
>>   crypto:s5p-sss: Add device tree support
>>   crypto:s5p-sss: Add support for SSS module on Exynos
>>   crypto:s5p-sss: validate iv before memcpy
>>   crypto:s5p-sss: Use clk_prepare/clk_unprepare
>
> FWIW these patches are fine by me.
>
> Acked-by: Herbert Xu 
>
> Thanks,
Any update on this patchset. They are already reviewed by Tomasz
and Acked by Herbert.
Anything else to be done from my side.

> --
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/9 v6] ARM: dts: exynos5250/5420: add dt node for sss module

[Naveen Krishna Ch]

Hello Tomasz,

On 14 February 2014 16:24, Tomasz Figa  wrote:
> Hi Kukjin,
>
>
> On 14.02.2014 00:28, Kukjin Kim wrote:
>>
>> On 02/07/14 14:24, Naveen Krishna Chatradhi wrote:
>>>
>>> This patch adds the device tree node for SSS module
>>> found on Exynos5420 and Exynos5250
>>>
>>> Signed-off-by: Naveen Krishna Chatradhi
>>> Reviewed-by: Tomasz Figa
>>> TO:
>>> CC: Kukjin Kim
>>> CC:
>>> ---
>>> changes since v5:
>>> 1. Added Reviewed-by: Tomasz Figa
>>>
>>>   arch/arm/boot/dts/exynos5250.dtsi |8 
>>>   arch/arm/boot/dts/exynos5420.dtsi |   10 ++
>>>   2 files changed, 18 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
>>> b/arch/arm/boot/dts/exynos5250.dtsi
>>> index b7dec41..46b04e8 100644
>>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>>> @@ -706,4 +706,12 @@
>>>   io-channel-ranges;
>>>   status = "disabled";
>>>   };
>>> +
>>> +sss@1083 {
>>> +compatible = "samsung,exynos4210-secss";
>>> +reg =<0x1083 0x1>;
>>> +interrupts =<0 112 0>;
>>> +clocks =<&clock 348>;
>>> +clock-names = "secss";
>>> +};
>>>   };
>>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
>>> b/arch/arm/boot/dts/exynos5420.dtsi
>>> index 8db792b..b503e96 100644
>>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>>> @@ -652,4 +652,14 @@
>>>   clocks =<&clock 319>,<&clock 318>;
>>>   clock-names = "tmu_apbif", "tmu_triminfo_apbif";
>>>   };
>>> +
>>> +sss@1083 {
>>> +compatible = "samsung,exynos4210-secss";
>>> +reg =<0x1083 0x1>;
>>> +interrupts =<0 112 0>;
>>> +clocks =<&clock 471>;
>>> +clock-names = "secss";
>>> +samsung,power-domain =<&g2d_pd>;
>>> +};
>>> +
>>>   };
>>
>>
>> Applied, thanks.
>>
>> BTW, I think the numbering is strange...maybe I missed something?
>> [PATCH 5/5], [PATCH 5/6 V2], [PATCH 6/8 V3] and this [PATCH 6/9 V6]
>
>
> I would wait with applying any patches from this series until they are acked
> by crypto subsystem maintainer and DT bindings by DT maintainers.
>
> I'd like Naveen to resend this series in separate thread, with proper
> message threading, so we can make sure that we are not missing anything.
> Naveen, please also add
Sure, i will respin the v6 version of this patchset without using the
In-Reply-To option.
>
> David S. Miller 
I've added David S.Miller for few of the patches, i will cc him for
all the patches.
>
> to Cc list, as he is also listed as crypto maintainer in MAINTAINERS file.
>
> Best regards,
> Tomasz
Sure, thanks Tomasz.



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/9 v6] ARM: dts: exynos5250/5420: add dt node for sss module

[Naveen Krishna Ch]

Hello Kukjin,

On 14 February 2014 05:02, Kukjin Kim  wrote:
> On 02/14/14 08:28, Kukjin Kim wrote:
>>
>> On 02/07/14 14:24, Naveen Krishna Chatradhi wrote:
>>>
>>> This patch adds the device tree node for SSS module
>>> found on Exynos5420 and Exynos5250
>>>
>>> Signed-off-by: Naveen Krishna Chatradhi
>>> Reviewed-by: Tomasz Figa
>>> TO:
>>> CC: Kukjin Kim
>>> CC:
>>> ---
>>> changes since v5:
>>> 1. Added Reviewed-by: Tomasz Figa
>>>
>>> arch/arm/boot/dts/exynos5250.dtsi | 8 
>>> arch/arm/boot/dts/exynos5420.dtsi | 10 ++
>>> 2 files changed, 18 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
>>> b/arch/arm/boot/dts/exynos5250.dtsi
>>> index b7dec41..46b04e8 100644
>>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>>> @@ -706,4 +706,12 @@
>>> io-channel-ranges;
>>> status = "disabled";
>>> };
>>> +
>>> + sss@1083 {
>>> + compatible = "samsung,exynos4210-secss";
>>> + reg =<0x1083 0x1>;
>>> + interrupts =<0 112 0>;
>>> + clocks =<&clock 348>;
>>> + clock-names = "secss";
>>> + };
>>> };
>>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
>>> b/arch/arm/boot/dts/exynos5420.dtsi
>>> index 8db792b..b503e96 100644
>>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>>> @@ -652,4 +652,14 @@
>>> clocks =<&clock 319>,<&clock 318>;
>>> clock-names = "tmu_apbif", "tmu_triminfo_apbif";
>>> };
>>> +
>>> + sss@1083 {
>>> + compatible = "samsung,exynos4210-secss";
>>> + reg =<0x1083 0x1>;
>>> + interrupts =<0 112 0>;
>>> + clocks =<&clock 471>;
>>> + clock-names = "secss";
>>> + samsung,power-domain =<&g2d_pd>;
>>> + };
>>> +
>>> };
>>
>>
>> Applied, thanks.
>>
>> BTW, I think the numbering is strange...maybe I missed something?
>> [PATCH 5/5], [PATCH 5/6 V2], [PATCH 6/8 V3] and this [PATCH 6/9 V6]
>>
> Oops, Naveen, where is bindings doc for "samsung,exynos4210-secss"?
The binding doc patch is along with the driver patch
https://groups.google.com/forum/#!msg/linux.kernel/9Z02Gg_MzPA/GTc7Csg74L0J
and
http://patchwork.ozlabs.org/patch/314946/
>
> - Kukjin



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] thermal: exynos: handle gate clock for misplaced TRIMINFO register

[Naveen Krishna Ch]

Hello Mark,

On 10 February 2014 16:37, Mark Rutland  wrote:
> On Mon, Feb 10, 2014 at 10:50:01AM +0000, Naveen Krishna Ch wrote:
>> Hello Mark,
>>
>> On 10 February 2014 16:03, Mark Rutland  wrote:
>> > On Thu, Nov 07, 2013 at 12:42:34PM +, Naveen Krishna Chatradhi wrote:
>> >> On Exynos5420 the TMU(4) for GPU has a seperate clock enable bit from
>> >> the other TMU channels(0 ~ 3). Hence, accessing TRIMINFO for base_second
>> >> should be acompanied by enabling the respective clock.
>> >>
>> >> This patch which allow for a "clk_sec" clock to be specified in the
>> >> device-tree which will be ungated when accessing the TRIMINFO register.
>> >
>> > Missing binding document update? Or was "clk_sec" originally in the
>> > binding but unused?
>> >
>> > The code seems to expect "tmu_apbif_sec" as the clock name in the DT,
>> > but this isn't mentioned in the commit message.
>> >
>> > I grepped Documentation/devicetree in mainline, but found no reference
>> > of either.
>> >
>> > Thanks,
>> > Mark.
>> This CL is to be abandoned.
>
> Ok.
>
>>
>> As mentioned in the previous replies to this patch.
>> The changes in this patched were merged with
>> http://www.spinics.net/lists/devicetree/msg15165.html
>>
>> The latest patch set can be found at.
>> 1. http://www.spinics.net/lists/devicetree/msg15163.html
>> 2. http://www.spinics.net/lists/devicetree/msg15164.html
>> 3. http://www.spinics.net/lists/devicetree/msg15165.html
>> 4. http://www.spinics.net/lists/devicetree/msg15165.html
>
> I responded here because of your ping message on 2014-02-07. The latest
> patches seem to have been posted before that. Was the ping misplaced or
> have I misunderstood?
It was my bad, I replied to the patches in that series and i myself forgot that
it was abandoned patch. Sorry.
>
> Thanks,
> Mark



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] thermal: exynos: handle gate clock for misplaced TRIMINFO register

[Naveen Krishna Ch]

Hello Mark,

On 10 February 2014 16:03, Mark Rutland  wrote:
> On Thu, Nov 07, 2013 at 12:42:34PM +, Naveen Krishna Chatradhi wrote:
>> On Exynos5420 the TMU(4) for GPU has a seperate clock enable bit from
>> the other TMU channels(0 ~ 3). Hence, accessing TRIMINFO for base_second
>> should be acompanied by enabling the respective clock.
>>
>> This patch which allow for a "clk_sec" clock to be specified in the
>> device-tree which will be ungated when accessing the TRIMINFO register.
>
> Missing binding document update? Or was "clk_sec" originally in the
> binding but unused?
>
> The code seems to expect "tmu_apbif_sec" as the clock name in the DT,
> but this isn't mentioned in the commit message.
>
> I grepped Documentation/devicetree in mainline, but found no reference
> of either.
>
> Thanks,
> Mark.
This CL is to be abandoned.

As mentioned in the previous replies to this patch.
The changes in this patched were merged with
http://www.spinics.net/lists/devicetree/msg15165.html

The latest patch set can be found at.
1. http://www.spinics.net/lists/devicetree/msg15163.html
2. http://www.spinics.net/lists/devicetree/msg15164.html
3. http://www.spinics.net/lists/devicetree/msg15165.html
4. http://www.spinics.net/lists/devicetree/msg15165.html

Thanks for your time.
>
>>
>> Signed-off-by: Andrew Bresticker 
>> Signed-off-by: Naveen Krishna Chatradhi 
>> ---
>>  drivers/thermal/samsung/exynos_tmu.c |   24 +++-
>>  1 file changed, 23 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
>> b/drivers/thermal/samsung/exynos_tmu.c
>> index b54825a..33edd1a 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -47,6 +47,7 @@
>>   * @irq_work: pointer to the irq work structure.
>>   * @lock: lock to implement synchronization.
>>   * @clk: pointer to the clock structure.
>> + * @clk_sec: pointer to the clock structure for accessing the base_second.
>>   * @temp_error1: fused value of the first point trim.
>>   * @temp_error2: fused value of the second point trim.
>>   * @regulator: pointer to the TMU regulator structure.
>> @@ -61,7 +62,7 @@ struct exynos_tmu_data {
>>   enum soc_type soc;
>>   struct work_struct irq_work;
>>   struct mutex lock;
>> - struct clk *clk;
>> + struct clk *clk, *clk_sec;
>>   u8 temp_error1, temp_error2;
>>   struct regulator *regulator;
>>   struct thermal_sensor_conf *reg_conf;
>> @@ -152,6 +153,8 @@ static int exynos_tmu_initialize(struct platform_device 
>> *pdev)
>>
>>   mutex_lock(&data->lock);
>>   clk_enable(data->clk);
>> + if (!IS_ERR(data->clk_sec))
>> + clk_enable(data->clk_sec);
>>
>>   if (TMU_SUPPORTS(pdata, READY_STATUS)) {
>>   status = readb(data->base + reg->tmu_status);
>> @@ -306,6 +309,8 @@ skip_calib_data:
>>  out:
>>   clk_disable(data->clk);
>>   mutex_unlock(&data->lock);
>> + if (!IS_ERR(data->clk_sec))
>> + clk_disable(data->clk_sec);
>>
>>   return ret;
>>  }
>> @@ -457,12 +462,16 @@ static void exynos_tmu_work(struct work_struct *work)
>>   const struct exynos_tmu_registers *reg = pdata->registers;
>>   unsigned int val_irq, val_type;
>>
>> + if (!IS_ERR(data->clk_sec))
>> + clk_enable(data->clk_sec);
>>   /* Find which sensor generated this interrupt */
>>   if (reg->tmu_irqstatus) {
>>   val_type = readl(data->base_second + reg->tmu_irqstatus);
>>   if (!((val_type >> data->id) & 0x1))
>>   goto out;
>>   }
>> + if (!IS_ERR(data->clk_sec))
>> + clk_disable(data->clk_sec);
>>
>>   exynos_report_trigger(data->reg_conf);
>>   mutex_lock(&data->lock);
>> @@ -641,6 +650,15 @@ static int exynos_tmu_probe(struct platform_device 
>> *pdev)
>>   if (ret)
>>   return ret;
>>
>> + data->clk_sec = devm_clk_get(&pdev->dev, "tmu_apbif_sec");
>> + if (!IS_ERR(data->clk_sec)) {
>> + ret = clk_prepare(data->clk_sec);
>> + if (ret) {
>> + dev_err(&pdev->dev, "Failed to get clock\n");
>> + return  PTR_ERR(data->clk_sec);
>> + }
>> + }
>> +
>>   if (pdata->type == SOC_ARCH_EXYNOS4210 ||
>>   pdata->type == SOC_ARCH_EXYNOS4412 ||
>>   pdata->type == SOC_ARCH_EXYNOS5250 ||
>> @@ -713,6 +731,8 @@ static int exynos_tmu_probe(struct platform_device *pdev)
>>   return 0;
>>  err_clk:
>>   clk_unprepare(data->clk);
>> + if (!IS_ERR(data->clk_sec))
>> + clk_unprepare(data->clk_sec);
>>   return ret;
>>  }
>>
>> @@ -725,6 +745,8 @@ static int exynos_tmu_remove(struct platform_device 
>> *pdev)
>>   exynos_unregister_thermal(data->reg_conf);
>>
>>   clk_unprepare(data->clk);
>> + if (!IS_ERR(data->clk_sec))
>> + clk_unprepare(data->clk_sec);
>>
>>   if (!IS_ERR(data->regulator))
>>   regulato

Re: [PATCH v12 2/4] thermal: samsung: change base_common to more meaningful base_second

[Naveen Krishna Ch]

Hello All,

On 19 December 2013 11:36, Naveen Krishna Chatradhi
 wrote:
> On Exynos5440 and Exynos5420 there are registers common
> across the TMU channels.
>
> To support that, we introduced a ADDRESS_MULTIPLE flag in the
> driver and the 2nd set of register base and size are provided
> in the "reg" property of the node.
>
> As per Amit's suggestion, this patch changes the base_common
> to base_second and SHARED_MEMORY to ADDRESS_MULTIPLE.
>
> Signed-off-by: Naveen Krishna Chatradhi 
> Acked-by: Amit Daniel Kachhap 
> Reviewed-by: Bartlomiej Zolnierkiewicz 
> Reviewed-by: Tomasz Figa 
> ---
> Changes since v11:
> Added Reviewed by Tomasz
>
> Changes since v10:
> Documentation rephrased as per comments from Tomasz Figa
>
>  .../devicetree/bindings/thermal/exynos-thermal.txt   |4 ++--
>  drivers/thermal/samsung/exynos_tmu.c |   14 
> +++---
>  drivers/thermal/samsung/exynos_tmu.h |4 ++--
>  drivers/thermal/samsung/exynos_tmu_data.c|2 +-
>  4 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> index 284f530..a1aa602 100644
> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> @@ -11,8 +11,8 @@
>  - reg : Address range of the thermal registers. For soc's which has multiple
> instances of TMU and some registers are shared across all TMU's like
> interrupt related then 2 set of register has to supplied. First set
> -   belongs to each instance of TMU and second set belongs to common TMU
> -   registers.
> +   belongs to register set of TMU instance and second set belongs to
> +   registers shared with the TMU instance.
>  - interrupts : Should contain interrupt for thermal system
>  - clocks : The main clock for TMU device
>  - clock-names : Thermal system clock name
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index c493245..bbd0fc3 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -41,7 +41,7 @@
>   * @id: identifier of the one instance of the TMU controller.
>   * @pdata: pointer to the tmu platform/configuration data
>   * @base: base address of the single instance of the TMU controller.
> - * @base_common: base address of the common registers of the TMU controller.
> + * @base_second: base address of the common registers of the TMU controller.
>   * @irq: irq number of the TMU controller.
>   * @soc: id of the SOC type.
>   * @irq_work: pointer to the irq work structure.
> @@ -56,7 +56,7 @@ struct exynos_tmu_data {
> int id;
> struct exynos_tmu_platform_data *pdata;
> void __iomem *base;
> -   void __iomem *base_common;
> +   void __iomem *base_second;
> int irq;
> enum soc_type soc;
> struct work_struct irq_work;
> @@ -297,7 +297,7 @@ skip_calib_data:
> }
> /*Clear the PMIN in the common TMU register*/
> if (reg->tmu_pmin && !data->id)
> -   writel(0, data->base_common + reg->tmu_pmin);
> +   writel(0, data->base_second + reg->tmu_pmin);
>  out:
> clk_disable(data->clk);
> mutex_unlock(&data->lock);
> @@ -454,7 +454,7 @@ static void exynos_tmu_work(struct work_struct *work)
>
> /* Find which sensor generated this interrupt */
> if (reg->tmu_irqstatus) {
> -   val_type = readl(data->base_common + reg->tmu_irqstatus);
> +   val_type = readl(data->base_second + reg->tmu_irqstatus);
> if (!((val_type >> data->id) & 0x1))
> goto out;
> }
> @@ -579,7 +579,7 @@ static int exynos_map_dt_data(struct platform_device 
> *pdev)
>  * Check if the TMU shares some registers and then try to map the
>  * memory of common registers.
>  */
> -   if (!TMU_SUPPORTS(pdata, SHARED_MEMORY))
> +   if (!TMU_SUPPORTS(pdata, ADDRESS_MULTIPLE))
> return 0;
>
> if (of_address_to_resource(pdev->dev.of_node, 1, &res)) {
> @@ -587,9 +587,9 @@ static int exynos_map_dt_data(struct platform_device 
> *pdev)
> return -ENODEV;
> }
>
> -   data->base_common = devm_ioremap(&pdev->dev, res.start,
> +   data->base_second = devm_ioremap(&pdev->dev, res.start,
> resource_size(&res));
> -   if (!data->base_common) {
> +   if (!data->base_second) {
> dev_err(&pdev->dev, "Failed to ioremap memory\n");
> return -ENOMEM;
> }
> diff --git a/drivers/thermal/samsung/exynos_tmu.h 
> b/drivers/thermal/samsung/exynos_tmu.h
> index 980859a..0d6b32f 100644
> --- a/drivers/thermal/samsung/exynos_tmu.h
> +++ b/drivers/thermal/samsung/exynos_tmu.h
> @@

Re: [PATCH v12 3/4] thermal: samsung: Add TMU support for Exynos5420 SoCs

[Naveen Krishna Ch]

Hello All,

On 19 December 2013 17:04, Tomasz Figa  wrote:
> On Thursday 19 of December 2013 11:36:31 Naveen Krishna Chatradhi wrote:
>> Exynos5420 has 5 TMU channels, the TRIMINFO register is
>> misplaced for TMU channels 2, 3 and 4
>> TRIMINFO at 0x1006c000 contains data for TMU channel 3
>> TRIMINFO at 0x100a contains data for TMU channel 4
>> TRIMINFO at 0x10068000 contains data for TMU channel 2
>>
>> This patch
>> 1 Adds the neccessary register changes and arch information
>>to support Exynos5420 SoCs.
>> 2. Handles the gate clock for misplaced TRIMINFO register
>> 3. Updates the Documentation at
>>Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> Signed-off-by: Andrew Bresticker 
>> Acked-by: Amit Daniel Kachhap 
>> Reviewed-by: Bartlomiej Zolnierkiewicz 
>> ---
>> Changes since v11:
>> 1. Added description for clocks in the Documentation
>> 2. corrected the clock name in clk_get() function as per description
>>
>> Changes since v10:
>> 1. using renamed compatible "samsung,exynos5420-tmu-ext-triminfo"
>>and passing same clock as triminfo_apbif clock for channel 2
>> 2. removed the "exynos5420-tmu-triminfo-clk" compatible
>>  .../devicetree/bindings/thermal/exynos-thermal.txt |   45 -
>>  drivers/thermal/samsung/exynos_tmu.c   |   52 +-
>>  drivers/thermal/samsung/exynos_tmu.h   |1 +
>>  drivers/thermal/samsung/exynos_tmu_data.c  |   99 
>> 
>>  drivers/thermal/samsung/exynos_tmu_data.h  |8 ++
>>  5 files changed, 200 insertions(+), 5 deletions(-)
>
> Reviewed-by: Tomasz Figa 
>
> Best regards,
> Tomasz
>
Ping.



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] thermal: exynos: handle gate clock for misplaced TRIMINFO register

[Naveen Krishna Ch]

Hello All,

On 2 January 2014 11:37, Zhang Rui  wrote:
> On Thu, 2013-11-07 at 18:12 +0530, Naveen Krishna Chatradhi wrote:
>> On Exynos5420 the TMU(4) for GPU has a seperate clock enable bit from
>> the other TMU channels(0 ~ 3). Hence, accessing TRIMINFO for base_second
>> should be acompanied by enabling the respective clock.
>>
>> This patch which allow for a "clk_sec" clock to be specified in the
>> device-tree which will be ungated when accessing the TRIMINFO register.
>>
>> Signed-off-by: Andrew Bresticker 
>> Signed-off-by: Naveen Krishna Chatradhi 
>
> Eduardo,
>
> what do you think of this patch?
>
> thanks,
> rui
>> ---
>>  drivers/thermal/samsung/exynos_tmu.c |   24 +++-
>>  1 file changed, 23 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
>> b/drivers/thermal/samsung/exynos_tmu.c
>> index b54825a..33edd1a 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -47,6 +47,7 @@
>>   * @irq_work: pointer to the irq work structure.
>>   * @lock: lock to implement synchronization.
>>   * @clk: pointer to the clock structure.
>> + * @clk_sec: pointer to the clock structure for accessing the base_second.
>>   * @temp_error1: fused value of the first point trim.
>>   * @temp_error2: fused value of the second point trim.
>>   * @regulator: pointer to the TMU regulator structure.
>> @@ -61,7 +62,7 @@ struct exynos_tmu_data {
>>   enum soc_type soc;
>>   struct work_struct irq_work;
>>   struct mutex lock;
>> - struct clk *clk;
>> + struct clk *clk, *clk_sec;
>>   u8 temp_error1, temp_error2;
>>   struct regulator *regulator;
>>   struct thermal_sensor_conf *reg_conf;
>> @@ -152,6 +153,8 @@ static int exynos_tmu_initialize(struct platform_device 
>> *pdev)
>>
>>   mutex_lock(&data->lock);
>>   clk_enable(data->clk);
>> + if (!IS_ERR(data->clk_sec))
>> + clk_enable(data->clk_sec);
>>
>>   if (TMU_SUPPORTS(pdata, READY_STATUS)) {
>>   status = readb(data->base + reg->tmu_status);
>> @@ -306,6 +309,8 @@ skip_calib_data:
>>  out:
>>   clk_disable(data->clk);
>>   mutex_unlock(&data->lock);
>> + if (!IS_ERR(data->clk_sec))
>> + clk_disable(data->clk_sec);
>>
>>   return ret;
>>  }
>> @@ -457,12 +462,16 @@ static void exynos_tmu_work(struct work_struct *work)
>>   const struct exynos_tmu_registers *reg = pdata->registers;
>>   unsigned int val_irq, val_type;
>>
>> + if (!IS_ERR(data->clk_sec))
>> + clk_enable(data->clk_sec);
>>   /* Find which sensor generated this interrupt */
>>   if (reg->tmu_irqstatus) {
>>   val_type = readl(data->base_second + reg->tmu_irqstatus);
>>   if (!((val_type >> data->id) & 0x1))
>>   goto out;
>>   }
>> + if (!IS_ERR(data->clk_sec))
>> + clk_disable(data->clk_sec);
>>
>>   exynos_report_trigger(data->reg_conf);
>>   mutex_lock(&data->lock);
>> @@ -641,6 +650,15 @@ static int exynos_tmu_probe(struct platform_device 
>> *pdev)
>>   if (ret)
>>   return ret;
>>
>> + data->clk_sec = devm_clk_get(&pdev->dev, "tmu_apbif_sec");
>> + if (!IS_ERR(data->clk_sec)) {
>> + ret = clk_prepare(data->clk_sec);
>> + if (ret) {
>> + dev_err(&pdev->dev, "Failed to get clock\n");
>> + return  PTR_ERR(data->clk_sec);
>> + }
>> + }
>> +
>>   if (pdata->type == SOC_ARCH_EXYNOS4210 ||
>>   pdata->type == SOC_ARCH_EXYNOS4412 ||
>>   pdata->type == SOC_ARCH_EXYNOS5250 ||
>> @@ -713,6 +731,8 @@ static int exynos_tmu_probe(struct platform_device *pdev)
>>   return 0;
>>  err_clk:
>>   clk_unprepare(data->clk);
>> + if (!IS_ERR(data->clk_sec))
>> + clk_unprepare(data->clk_sec);
>>   return ret;
>>  }
>>
>> @@ -725,6 +745,8 @@ static int exynos_tmu_remove(struct platform_device 
>> *pdev)
>>   exynos_unregister_thermal(data->reg_conf);
>>
>>   clk_unprepare(data->clk);
>> + if (!IS_ERR(data->clk_sec))
>> + clk_unprepare(data->clk_sec);
>>
>>   if (!IS_ERR(data->regulator))
>>   regulator_disable(data->regulator);
>
>
Ping.



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v12 1/4] thermal: samsung: replace inten_ bit fields with intclr_

[Naveen Krishna Ch]

Hello All,

On 2 January 2014 08:03, Zhang Rui  wrote:
> On Thu, 2013-12-19 at 11:35 +0530, Naveen Krishna Chatradhi wrote:
>> This patch replaces the inten_rise_shift/mask and inten_fall_shift/mask
>> with intclr_rise_shift/mask and intclr_fall_shift/mask respectively.
>> Currently, inten_rise_shift/mask and inten_fall_shift/mask bits are only used
>> to configure intclr related registers.
>>
>> Description of H/W:
>> The offset for the bits in the CLEAR register are not consistent across TMU
>> modules in Exynso5250, 5420 and 5440.
>>
>> On Exynos5250, the FALL interrupt related en, status and clear bits are
>> available at an offset of
>> 16 in INTEN, INTSTAT registers and at an offset of
>> 12 in INTCLEAR register.
>>
>> On Exynos5420, the FALL interrupt related en, status and clear bits are
>> available at an offset of
>> 16 in INTEN, INTSTAT and INTCLEAR registers.
>>
>> On Exynos5440,
>> the FALL_IRQEN bits are at an offset of 4
>> and the RISE_IRQEN bits are at an offset of 0
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> Acked-by: Amit Daniel Kachhap 
>> Reviewed-by: Bartlomiej Zolnierkiewicz 
>> Reviewed-by: Tomasz Figa 
>
> Eduardo,
>
> what do you think of this patch set?
>
> thanks,
> rui
>> ---
>> Changes since v11:
>> Added Reviewed by Tomasz
>>
>> Changes since v10:
>> None
>>
>>  drivers/thermal/samsung/exynos_tmu.c  |6 +++---
>>  drivers/thermal/samsung/exynos_tmu.h  |   16 
>>  drivers/thermal/samsung/exynos_tmu_data.c |   18 +-
>>  drivers/thermal/samsung/exynos_tmu_data.h |4 ++--
>>  4 files changed, 22 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
>> b/drivers/thermal/samsung/exynos_tmu.c
>> index 32f38b9..c493245 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -237,7 +237,7 @@ skip_calib_data:
>>   writeb(pdata->trigger_levels[i], data->base +
>>   reg->threshold_th0 + i * sizeof(reg->threshold_th0));
>>
>> - writel(reg->inten_rise_mask, data->base + reg->tmu_intclear);
>> + writel(reg->intclr_rise_mask, data->base + reg->tmu_intclear);
>>   } else {
>>   /* Write temperature code for rising and falling threshold */
>>   for (i = 0;
>> @@ -264,8 +264,8 @@ skip_calib_data:
>>   writel(falling_threshold,
>>   data->base + reg->threshold_th1);
>>
>> - writel((reg->inten_rise_mask << reg->inten_rise_shift) |
>> - (reg->inten_fall_mask << reg->inten_fall_shift),
>> + writel((reg->intclr_rise_mask << reg->intclr_rise_shift) |
>> + (reg->intclr_fall_mask << reg->intclr_fall_shift),
>>   data->base + reg->tmu_intclear);
>>
>>   /* if last threshold limit is also present */
>> diff --git a/drivers/thermal/samsung/exynos_tmu.h 
>> b/drivers/thermal/samsung/exynos_tmu.h
>> index 3fb6554..980859a 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.h
>> +++ b/drivers/thermal/samsung/exynos_tmu.h
>> @@ -122,10 +122,6 @@ enum soc_type {
>>   * @threshold_th3_l0_shift: shift bits of level0 threshold temperature.
>>   * @tmu_inten: register containing the different threshold interrupt
>>   enable bits.
>> - * @inten_rise_shift: shift bits of all rising interrupt bits.
>> - * @inten_rise_mask: mask bits of all rising interrupt bits.
>> - * @inten_fall_shift: shift bits of all rising interrupt bits.
>> - * @inten_fall_mask: mask bits of all rising interrupt bits.
>>   * @inten_rise0_shift: shift bits of rising 0 interrupt bits.
>>   * @inten_rise1_shift: shift bits of rising 1 interrupt bits.
>>   * @inten_rise2_shift: shift bits of rising 2 interrupt bits.
>> @@ -136,6 +132,10 @@ enum soc_type {
>>   * @inten_fall3_shift: shift bits of falling 3 interrupt bits.
>>   * @tmu_intstat: Register containing the interrupt status values.
>>   * @tmu_intclear: Register for clearing the raised interrupt status.
>> + * @intclr_fall_shift: shift bits for interrupt clear fall 0
>> + * @intclr_rise_shift: shift bits of all rising interrupt bits.
>> + * @intclr_rise_mask: mask bits of all rising interrupt bits.
>> + * @intclr_fall_mask: mask bits of all rising interrupt bits.
>>   * @emul_con: TMU emulation controller register.
>>   * @emul_temp_shift: shift bits of emulation temperature.
>>   * @emul_time_shift: shift bits of emulation time.
>> @@ -191,10 +191,6 @@ struct exynos_tmu_registers {
>>   u32 threshold_th3_l0_shift;
>>
>>   u32 tmu_inten;
>> - u32 inten_rise_shift;
>> - u32 inten_rise_mask;
>> - u32 inten_fall_shift;
>> - u32 inten_fall_mask;
>>   u32 inten_rise0_shift;
>>   u32 inten_rise1_shift;
>>   u32 inten_rise2_shift;
>> @@ -207,6 +203,10 @@ struct exynos_tmu_registers {
>>   u32 tmu_intstat;
>>
>>   u32 tmu_intclear;
>> + u3

Re: [PATCH 1/2] i2c-s3c2410: Leave the bus disabled unless it is in use

[Naveen Krishna Ch]

Hello Wolfram,

Sorry for a replying after really long time.

On 24 January 2013 17:50, Wolfram Sang  wrote:
> On Thu, Nov 29, 2012 at 10:35:34AM +0530, Naveen Krishna Chatradhi wrote:
>> From: Simon Glass 
>>
>> There is a rather odd feature of the exynos i2c controller that if it
>> is left enabled, it can lock itself up with the clk line held low.
>> This makes the bus unusable.
>>
>> Unfortunately, the s3c24xx_i2c_set_master() function does not notice
>> this, and reports a timeout. From then on the bus cannot be used until
>> the AP is rebooted.
>>
>> The problem happens when any sort of interrupt occurs (e.g. due to a
>> bus transition) when we are not in the middle of a transaction. We
>> have seen many instances of this when U-Boot leaves the bus apparently
>> happy, but Linux cannot access it.
>>
>> The current code is therefore pretty fragile.
>>
>> This fixes things by leaving the bus disabled unless we are actually
>> in a transaction. We enable the bus at the start of the transaction and
>> disable it at the end. That way we won't get interrupts and will not
>> lock up the bus.
>>
>> It might be possible to clear pending interrupts on start-up, but this
>> seems to be a more robust solution. We can't service interrupts when
>> we are not in a transaction, and anyway would rather not lock up the
>> bus while we try.
>>
>> Signed-off-by: Simon Glass 
>> Cc: Grant Grundler 
>> Signed-off-by: Naveen Krishna Chatradhi 
>
> So, I assume this patch is still needed despite the ongoing discussion
> about arbitration?
Yes, this is an i2c crontroller fix.
>
>> ---
>>  drivers/i2c/busses/i2c-s3c2410.c |   37 
>> +
>>  1 file changed, 33 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-s3c2410.c 
>> b/drivers/i2c/busses/i2c-s3c2410.c
>> index e93e7d6..2fd346d 100644
>> --- a/drivers/i2c/busses/i2c-s3c2410.c
>> +++ b/drivers/i2c/busses/i2c-s3c2410.c
>> @@ -186,6 +186,31 @@ static inline void s3c24xx_i2c_enable_irq(struct 
>> s3c24xx_i2c *i2c)
>>   writel(tmp | S3C2410_IICCON_IRQEN, i2c->regs + S3C2410_IICCON);
>>  }
>>
>> +/*
>> + * Disable the bus so that we won't get any interrupts from now on, or try
>> + * to drive any lines. This is the default state when we don't have
>> + * anything to send/receive.
>> + *
>> + * If there is an event on the bus, or we have a pre-existing event at
>
> Otherwise, if...
>
>> + * kernel boot time, we may not notice the event and the I2C controller
>> + * will lock the bus with the I2C clock line low indefinitely.
>> + */
>> +static inline void s3c24xx_i2c_disable_bus(struct s3c24xx_i2c *i2c)
>> +{
>> + unsigned long tmp;
>> +
>> + /* Stop driving the I2C pins */
>> + tmp = readl(i2c->regs + S3C2410_IICSTAT);
>> + tmp &= ~S3C2410_IICSTAT_TXRXEN;
>> + writel(tmp, i2c->regs + S3C2410_IICSTAT);
>> +
>> + /* We don't expect any interrupts now, and don't want send acks */
>> + tmp = readl(i2c->regs + S3C2410_IICCON);
>> + tmp &= ~(S3C2410_IICCON_IRQEN | S3C2410_IICCON_IRQPEND |
>> + S3C2410_IICCON_ACKEN);
>> + writel(tmp, i2c->regs + S3C2410_IICCON);
>> +}
>> +
>>
>>  /* s3c24xx_i2c_message_start
>>   *
>> @@ -646,7 +671,11 @@ static int s3c24xx_i2c_doxfer(struct s3c24xx_i2c *i2c,
>>
>>   s3c24xx_i2c_wait_idle(i2c);
>>
>> + s3c24xx_i2c_disable_bus(i2c);
>> +
>>   out:
>> + i2c->state = STATE_IDLE;
>> +
>
> Why is the state change after the label?
As the interrupts are enabled in the beginning of this function.
and interrupts in STATE_IDLE needs handling in a different way.

This was added with the intention the irq routine will handle the cases
>
>>   return ret;
>>  }
>>
>> @@ -912,7 +941,6 @@ static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c 
>> *i2c)
>>
>>  static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
>>  {
>> - unsigned long iicon = S3C2410_IICCON_IRQEN | S3C2410_IICCON_ACKEN;
>>   struct s3c2410_platform_i2c *pdata;
>>   unsigned int freq;
>>
>> @@ -926,12 +954,12 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
>>
>>   dev_info(i2c->dev, "slave address 0x%02x\n", pdata->slave_addr);
>>
>> - writel(iicon, i2c->regs + S3C2410_IICCON);
>> + writel(0, i2c->regs + S3C2410_IICCON);
>> + writel(0, i2c->regs + S3C2410_IICSTAT);
>>
>>   /* we need to work out the divisors for the clock... */
>>
>>   if (s3c24xx_i2c_clockrate(i2c, &freq) != 0) {
>> - writel(0, i2c->regs + S3C2410_IICCON);
>>   dev_err(i2c->dev, "cannot meet bus frequency required\n");
>>   return -EINVAL;
>>   }
>> @@ -939,7 +967,8 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
>>   /* todo - check that the i2c lines aren't being dragged anywhere */
>>
>>   dev_info(i2c->dev, "bus frequency set to %d KHz\n", freq);
>> - dev_dbg(i2c->dev, "S3C2410_IICCON=0x%02lx\n", iicon);
>> + dev_dbg(i2c->dev, "S3C2410_IICCON=0x%02x\n",
>> + readl(i2c->regs + S3C2410_IICCO

Re: [PATCH 8/8 v4] crypto:s5p-sss: Use clk_prepare/clk_unprepare

[Naveen Krishna Ch]

Hello Sylwester,

On 23 January 2014 16:11, Sylwester Nawrocki  wrote:
> Hi,
>
> On 23/01/14 11:18, Naveen Krishna Ch wrote:
>> Hello All,
>>
>> On 15 January 2014 14:47, Naveen Krishna Chatradhi
>>  wrote:
>>> This patch set adds use of clk_prepare/clk_unprepare as
>>> required by generic clock framework.
>>>
>>> Signed-off-by: Naveen Krishna Chatradhi 
>>> Reviewed-by: Tomasz Figa 
>>> ---
>>> Changes since v3:
>>> None
>>>
>>>  drivers/crypto/s5p-sss.c |6 +++---
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
>>> index f7c66c7..870e794 100644
>>> --- a/drivers/crypto/s5p-sss.c
>>> +++ b/drivers/crypto/s5p-sss.c
>>> @@ -648,7 +648,7 @@ static int s5p_aes_probe(struct platform_device *pdev)
>>> return -ENOENT;
>>> }
>>>
>>> -   clk_enable(pdata->clk);
>>> +   clk_prepare_enable(pdata->clk);
>
> How about properly checking the return value ?
Sure, Thanks.
>
> --
> Thanks,
> Sylwester



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/8 v4] crypto:s5p-sss: Add device tree support

[Naveen Krishna Ch]

Hello All,

On 15 January 2014 14:44, Naveen Krishna Chatradhi
 wrote:
> This patch adds device tree support to the s5p-sss.c crypto driver.
>
> Also, Documentation under devicetree/bindings added.
>
> Signed-off-by: Naveen Krishna Ch 
> CC: Herbert Xu 
> CC: David S. Miller 
> CC: Vladimir Zapolskiy 
> TO: 
> CC: 
> ---
> Changes since v3:
> None
>
>  .../devicetree/bindings/crypto/samsung-sss.txt |   20 
> 
>  drivers/crypto/s5p-sss.c   |   10 +-
>  2 files changed, 29 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/crypto/samsung-sss.txt
>
> diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt 
> b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
> new file mode 100644
> index 000..2f9d7e4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
> @@ -0,0 +1,20 @@
> +Samsung SoC SSS (Security SubSystem) module
> +
> +The SSS module in S5PV210 SoC supports the following:
> +-- Feeder (FeedCtrl)
> +-- Advanced Encryption Standard (AES)
> +-- Data Encryption Standard (DES)/3DES
> +-- Public Key Accelerator (PKA)
> +-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
> +-- PRNG: Pseudo Random Number Generator
> +
> +Required properties:
> +
> +- compatible : Should contain entries for this and backward compatible
> +  SSS versions:
> +  - "samsung,s5pv210-secss" for S5PV210 SoC.
> +- reg : Offset and length of the register set for the module
> +- interrupts : the interrupt-specifier for the SSS module.
> +   Two interrupts "feed control and hash" in case of S5PV210
> +- clocks : the required gating clock for the SSS module.
> +- clock-names : the gating clock name to be requested in the SSS driver.
> diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
> index 93cddeb..2da5617 100644
> --- a/drivers/crypto/s5p-sss.c
> +++ b/drivers/crypto/s5p-sss.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -177,6 +178,12 @@ struct s5p_aes_dev {
>
>  static struct s5p_aes_dev *s5p_dev;
>
> +static const struct of_device_id s5p_sss_dt_match[] = {
> +   { .compatible = "samsung,s5pv210-secss", },
> +   { },
> +};
> +MODULE_DEVICE_TABLE(of, s5p_sss_dt_match);
> +
>  static void s5p_set_dma_indata(struct s5p_aes_dev *dev, struct scatterlist 
> *sg)
>  {
> SSS_WRITE(dev, FCBRDMAS, sg_dma_address(sg));
> @@ -676,7 +683,8 @@ static struct platform_driver s5p_aes_crypto = {
> .remove = s5p_aes_remove,
> .driver = {
> .owner  = THIS_MODULE,
> -   .name   = "s5p-secss",
> +   .name   = "s5pv210-secss",
> +   .of_match_table = s5p_sss_dt_match,
> },
>  };
>
> --
> 1.7.9.5
Any update on this patch, Please
>



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/8 v4] clk: samsung: exynos5250/5420: Add gate clock for SSS module

[Naveen Krishna Ch]

Hello All,

On 15 January 2014 14:46, Naveen Krishna Chatradhi
 wrote:
> This patch adds gating clock for SSS(Security SubSystem)
> module on Exynos5250/5420.
>
> Signed-off-by: Naveen Krishna Chatradhi 
> TO: 
> TO: Tomasz Figa 
> CC: Kukjin Kim 
> CC: 
> ---
> Changes since v3:
> 1. Rebased on to 
> https://git.kernel.org/pub/scm/linux/kernel/git/tfiga/samsung-clk.git
> 2. Added new ID for SSS clock on Exynos5250, with Documentation and
> 3. Added gate clocks definitions for SSS on Exynos5420 and Exynos5250
>
>  .../devicetree/bindings/clock/exynos5250-clock.txt |1 +
>  drivers/clk/samsung/clk-exynos5250.c   |1 +
>  drivers/clk/samsung/clk-exynos5420.c   |4 
>  include/dt-bindings/clock/exynos5250.h |1 +
>  4 files changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt 
> b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> index 492ed09..a845fc6 100644
> --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
> @@ -162,6 +162,7 @@ clock which they consume.
>g2d  345
>mdma0346
>smmu_mdma0   347
> +  sss  348
>
>
> [Clock Muxes]
> diff --git a/drivers/clk/samsung/clk-exynos5250.c 
> b/drivers/clk/samsung/clk-exynos5250.c
> index ff4beeb..2c52fe1 100644
> --- a/drivers/clk/samsung/clk-exynos5250.c
> +++ b/drivers/clk/samsung/clk-exynos5250.c
> @@ -387,6 +387,7 @@ static struct samsung_gate_clock exynos5250_gate_clks[] 
> __initdata = {
>  * CMU_ACP
>  */
> GATE(CLK_MDMA0, "mdma0", "div_aclk266", GATE_IP_ACP, 1, 0, 0),
> +   GATE(CLK_SSS, "sss", "div_aclk266", GATE_IP_ACP, 2, 0, 0),
> GATE(CLK_G2D, "g2d", "div_aclk200", GATE_IP_ACP, 3, 0, 0),
> GATE(CLK_SMMU_MDMA0, "smmu_mdma0", "div_aclk266", GATE_IP_ACP, 5, 0, 
> 0),
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c 
> b/drivers/clk/samsung/clk-exynos5420.c
> index ab4f2f7..94915bb 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -26,6 +26,7 @@
>  #define DIV_CPU1   0x504
>  #define GATE_BUS_CPU   0x700
>  #define GATE_SCLK_CPU  0x800
> +#define GATE_BUS_G2D   0x8700
>  #define CPLL_LOCK  0x10020
>  #define DPLL_LOCK  0x10030
>  #define EPLL_LOCK  0x10040
> @@ -702,6 +703,9 @@ static struct samsung_gate_clock exynos5420_gate_clks[] 
> __initdata = {
> 0),
> GATE(CLK_SMMU_MIXER, "smmu_mixer", "aclk200_disp1", GATE_IP_DISP1, 9, 
> 0,
> 0),
> +
> +   /* SSS */
> +   GATE(CLK_SSS, "sss", "aclk266_g2d", GATE_BUS_G2D, 2, 0, 0),
>  };
>
>  static struct samsung_pll_clock exynos5420_plls[nr_plls] __initdata = {
> diff --git a/include/dt-bindings/clock/exynos5250.h 
> b/include/dt-bindings/clock/exynos5250.h
> index 922f2dc..f9b452b 100644
> --- a/include/dt-bindings/clock/exynos5250.h
> +++ b/include/dt-bindings/clock/exynos5250.h
> @@ -150,6 +150,7 @@
>  #define CLK_G2D345
>  #define CLK_MDMA0  346
>  #define CLK_SMMU_MDMA0 347
> +#define CLK_SSS348
>
>  /* mux clocks */
>  #define CLK_MOUT_HDMI  1024
> --
> 1.7.9.5
Any update on this patch, Please
>



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/8 v4] crypto:s5p-sss: Use platform_get_irq() instead of _byname()

[Naveen Krishna Ch]

Hello All,

On 15 January 2014 14:44, Naveen Krishna Chatradhi
 wrote:
> From: Naveen Krishna Ch 
>
> This patch uses the platform_get_irq() instead of the
> platform_get_irq_byname(). Making feeder control interrupt
> as resource "0" and hash interrupt as "1".
>
> reasons for this change.
> 1. Cannot find any Arch which is currently using this driver
> 2. Samsung Exynos4 and 5 SoCs only use the feeder control interrupt
> 3. Patches adding support for DT and H/W version are in pipeline
>
> Signed-off-by: Naveen Krishna Ch 
> Reviewed-by: Tomasz Figa 
> CC: Herbert Xu 
> CC: David S. Miller 
> CC: Vladimir Zapolskiy 
> TO: 
> CC: 
> ---
> Changes since v3:
> None
>
>  drivers/crypto/s5p-sss.c |   24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
> index cf149b1..93cddeb 100644
> --- a/drivers/crypto/s5p-sss.c
> +++ b/drivers/crypto/s5p-sss.c
> @@ -592,29 +592,29 @@ static int s5p_aes_probe(struct platform_device *pdev)
> pdata->ioaddr = devm_ioremap(dev, res->start,
>  resource_size(res));
>
> -   pdata->irq_hash = platform_get_irq_byname(pdev, "hash");
> -   if (pdata->irq_hash < 0) {
> -   err = pdata->irq_hash;
> -   dev_warn(dev, "hash interrupt is not available.\n");
> +   pdata->irq_fc = platform_get_irq(pdev, 0);
> +   if (pdata->irq_fc < 0) {
> +   err = pdata->irq_fc;
> +   dev_warn(dev, "feed control interrupt is not available.\n");
> goto err_irq;
> }
> -   err = devm_request_irq(dev, pdata->irq_hash, s5p_aes_interrupt,
> +   err = devm_request_irq(dev, pdata->irq_fc, s5p_aes_interrupt,
>IRQF_SHARED, pdev->name, pdev);
> if (err < 0) {
> -   dev_warn(dev, "hash interrupt is not available.\n");
> +   dev_warn(dev, "feed control interrupt is not available.\n");
> goto err_irq;
> }
>
> -   pdata->irq_fc = platform_get_irq_byname(pdev, "feed control");
> -   if (pdata->irq_fc < 0) {
> -   err = pdata->irq_fc;
> -   dev_warn(dev, "feed control interrupt is not available.\n");
> +   pdata->irq_hash = platform_get_irq(pdev, 1);
> +   if (pdata->irq_hash < 0) {
> +   err = pdata->irq_hash;
> +   dev_warn(dev, "hash interrupt is not available.\n");
> goto err_irq;
> }
> -   err = devm_request_irq(dev, pdata->irq_fc, s5p_aes_interrupt,
> +   err = devm_request_irq(dev, pdata->irq_hash, s5p_aes_interrupt,
>IRQF_SHARED, pdev->name, pdev);
> if (err < 0) {
> -   dev_warn(dev, "feed control interrupt is not available.\n");
> +   dev_warn(dev, "hash interrupt is not available.\n");
> goto err_irq;
> }
>
> --
> 1.7.9.5
Any update on this patch, Please
>



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 7/8 v4] crypto:s5p-sss: validate iv before memcpy

[Naveen Krishna Ch]

Hello All,

On 15 January 2014 14:47, Naveen Krishna Chatradhi
 wrote:
> This patch adds code to validate "iv" buffer before trying to
> memcpy the contents
>
> Signed-off-by: Naveen Krishna Chatradhi 
> ---
> Changes since v3:
> None
>
>  drivers/crypto/s5p-sss.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
> index 69130b2..f7c66c7 100644
> --- a/drivers/crypto/s5p-sss.c
> +++ b/drivers/crypto/s5p-sss.c
> @@ -380,7 +380,8 @@ static void s5p_set_aes(struct s5p_aes_dev *dev,
>  {
> void __iomem *keystart;
>
> -   memcpy(dev->aes_ioaddr + SSS_REG_AES_IV_DATA (0), iv, 0x10);
> +   if (iv)
> +   memcpy(dev->aes_ioaddr + SSS_REG_AES_IV_DATA (0), iv, 0x10);
>
> if (keylen == AES_KEYSIZE_256)
> keystart = dev->aes_ioaddr + SSS_REG_AES_KEY_DATA(0);
> --
> 1.7.9.5
Any update on this patch, Please
>



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/8 v4] ARM: dts: exynos5250/5420: add dt node for sss module

[Naveen Krishna Ch]

Hello All,

On 15 January 2014 14:46, Naveen Krishna Chatradhi
 wrote:
> This patch adds the device tree node for SSS module
> found on Exynos5420 and Exynos5250
>
> Signed-off-by: Naveen Krishna Chatradhi 
> Reviewed-by: Tomasz Figa 
> TO: 
> CC: Kukjin Kim 
> CC: 
> ---
> Changes since v3:
> 1. Modified the SSS clock ID as per dt-bindings for Exynos5250 in
>samsung-clk.git tree.
>
>  arch/arm/boot/dts/exynos5250.dtsi |8 
>  arch/arm/boot/dts/exynos5420.dtsi |   10 ++
>  2 files changed, 18 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
> b/arch/arm/boot/dts/exynos5250.dtsi
> index c341e55..1d249df 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -704,4 +704,12 @@
> io-channel-ranges;
> status = "disabled";
> };
> +
> +   sss@1083 {
> +   compatible = "samsung,exynos4210-secss";
> +   reg = <0x1083 0x1>;
> +   interrupts = <0 112 0>;
> +   clocks = <&clock 348>;
> +   clock-names = "secss";
> +   };
>  };
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
> b/arch/arm/boot/dts/exynos5420.dtsi
> index 11dd202..56a3f3e 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -652,4 +652,14 @@
> clocks = <&clock 319>, <&clock 318>;
> clock-names = "tmu_apbif", "tmu_triminfo_apbif";
> };
> +
> +   sss@1083 {
> +   compatible = "samsung,exynos4210-secss";
> +   reg = <0x1083 0x1>;
> +   interrupts = <0 112 0>;
> +   clocks = <&clock 471>;
> +   clock-names = "secss";
> +   samsung,power-domain = <&g2d_pd>;
> +   };
> +
>  };
> --
> 1.7.9.5
Any update on this patch, Please
>



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 8/8 v4] crypto:s5p-sss: Use clk_prepare/clk_unprepare

[Naveen Krishna Ch]

Hello All,

On 15 January 2014 14:47, Naveen Krishna Chatradhi
 wrote:
> This patch set adds use of clk_prepare/clk_unprepare as
> required by generic clock framework.
>
> Signed-off-by: Naveen Krishna Chatradhi 
> Reviewed-by: Tomasz Figa 
> ---
> Changes since v3:
> None
>
>  drivers/crypto/s5p-sss.c |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
> index f7c66c7..870e794 100644
> --- a/drivers/crypto/s5p-sss.c
> +++ b/drivers/crypto/s5p-sss.c
> @@ -648,7 +648,7 @@ static int s5p_aes_probe(struct platform_device *pdev)
> return -ENOENT;
> }
>
> -   clk_enable(pdata->clk);
> +   clk_prepare_enable(pdata->clk);
>
> spin_lock_init(&pdata->lock);
> pdata->ioaddr = devm_ioremap(dev, res->start,
> @@ -711,7 +711,7 @@ static int s5p_aes_probe(struct platform_device *pdev)
> tasklet_kill(&pdata->tasklet);
>
>   err_irq:
> -   clk_disable(pdata->clk);
> +   clk_disable_unprepare(pdata->clk);
>
> s5p_dev = NULL;
>
> @@ -731,7 +731,7 @@ static int s5p_aes_remove(struct platform_device *pdev)
>
> tasklet_kill(&pdata->tasklet);
>
> -   clk_disable(pdata->clk);
> +   clk_disable_unprepare(pdata->clk);
>
> s5p_dev = NULL;
>
> --
> 1.7.9.5
Any update on this patch, Please
>



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/8 v3] clk:exynos-5250: Add gate clock for SSS module

[Naveen Krishna Ch]

Hello Tomasz,

On 10 January 2014 21:28, Tomasz Figa  wrote:
> Hi Naveen,
>
>
> On 10.01.2014 12:43, Naveen Krishna Chatradhi wrote:
>>
>> This patch adds gating clock for SSS(Security SubSystem)
>> module on Exynos5250.
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> ---
>> Changes since v2:
>> This is a new change to support SSS on Exynos5250
>>
>>   drivers/clk/samsung/clk-exynos5250.c |3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/samsung/clk-exynos5250.c
>> b/drivers/clk/samsung/clk-exynos5250.c
>> index adf3234..b47bf0a 100644
>> --- a/drivers/clk/samsung/clk-exynos5250.c
>> +++ b/drivers/clk/samsung/clk-exynos5250.c
>> @@ -120,7 +120,7 @@ enum exynos5250_clks {
>> spi2, i2s1, i2s2, pcm1, pcm2, pwm, spdif, ac97, hsi2c0, hsi2c1,
>> hsi2c2,
>> hsi2c3, chipid, sysreg, pmu, cmu_top, cmu_core, cmu_mem, tzpc0,
>> tzpc1,
>> tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec,
>> mct,
>> -   wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi, g2d,
>> +   wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi, g2d, sss,
>
>
> Please base changes to Samsung clock drivers on Mike Turquette's clk-next
> [1] or ideally on my samsung-next branch on samsung-clk-tree [2].
>
> By the way, if you assign an ID to a clock, you need to document this in
> respective clock bindings documentation.
>
> [1] - https://git.linaro.org/people/mike.turquette/linux.git
> [2] - https://git.kernel.org/cgit/linux/kernel/git/tfiga/samsung-clk.git/
Sure Tomasz, Will rebase this changes on to your samsung-clk.git tree
>
> Best regards,
> Tomasz



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 7/8 v3] crypto:s5p-sss: validate iv before memcpy

[Naveen Krishna Ch]

Hello Tomasz,

On 10 January 2014 21:33, Tomasz Figa  wrote:
> Hi Naveen,
>
>
> On 10.01.2014 12:45, Naveen Krishna Chatradhi wrote:
>>
>> This patch adds code to validate "iv" buffer before trying to
>> memcpy the contents
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> ---
>> Changes since v2:
>> None
>>
>>   drivers/crypto/s5p-sss.c |5 +++--
>>   1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
>> index f274f5f..7058bb6 100644
>> --- a/drivers/crypto/s5p-sss.c
>> +++ b/drivers/crypto/s5p-sss.c
>> @@ -381,8 +381,9 @@ static void s5p_set_aes(struct s5p_aes_dev *dev,
>> struct samsung_aes_variant *var = dev->variant;
>> void __iomem *keystart;
>>
>> -   memcpy(dev->ioaddr + SSS_REG_AES_IV_DATA
>> -   (var->aes_offset, 0), iv, 0x10);
>> +   if (iv)
>> +   memcpy(dev->ioaddr + SSS_REG_AES_IV_DATA
>> +   (var->aes_offset, 0), iv, 0x10);
>
>
> In what conditions can the iv end up being NULL?
req->info is the initialization vector in our case, which comes from user space.
Its good to have a check to avoid any crashes.

Also AES ECB mode does not use IV.
>
> Best regards,
> Tomasz



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/8 v3] crypto:s5p-sss: Add support for SSS module on Exynos

[Naveen Krishna Ch]

Hell Vladimir, Tomasz,

On 14 January 2014 02:36, Vladimir Zapolskiy  wrote:
> Hi Naveen and Tomasz,
>
>
> On 01/10/14 17:44, Tomasz Figa wrote:
>>
>> Hi Naveen,
>>
>> Please see my comments inline.
>>
>> On 10.01.2014 12:42, Naveen Krishna Chatradhi wrote:
>>>
>>> This patch adds new compatible and variant struct to support the SSS
>>> module on Exynos4 (Exynos4210), Exynos5 (Exynos5420 and Exynos5250)
>>> for which
>>> 1. AES register are at an offset of 0x200 and
>>> 2. hash interrupt is not available
>>>
>>> Signed-off-by: Naveen Krishna Ch 
>>> CC: Herbert Xu 
>>> CC: David S. Miller 
>>> CC: Vladimir Zapolskiy 
>>> TO: 
>>> CC: 
>>> ---
>>> Changes since v2:
>>> 1. Added variant struct to handle the differences in SSS modules
>>> 2. Changed the compatible strings to exynos4210-secss
>>> 3. Other changes suggested by Tomasz
>>>
>>> .../devicetree/bindings/crypto/samsung-sss.txt | 20 
>>> drivers/crypto/s5p-sss.c | 110 +++-
>>> 2 files changed, 106 insertions(+), 24 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
>>> b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
>>> index 2f9d7e4..fdc7d8b 100644
>>> --- a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
>>> +++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
>>> @@ -8,13 +8,33 @@ The SSS module in S5PV210 SoC supports the following:
>>> -- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
>>> -- PRNG: Pseudo Random Number Generator
>>>
>>> +The SSS module in Exynos4 (Exynos4210) and
>>> +Exynos5 (Exynos5420 and Exynos5250) SoCs
>>> +supports the following also:
>>> +-- ARCFOUR (ARC4)
>>> +-- True Random Number Generator (TRNG)
>>> +-- Secure Key Manager
>>> +
>>> Required properties:
>>>
>>> - compatible : Should contain entries for this and backward compatible
>>> SSS versions:
>>> - "samsung,s5pv210-secss" for S5PV210 SoC.
>>> + - "samsung,exynos4210-secss" for Exynos4210, Exynos5250 and
>>> Exynos5420 SoCs.
>>
>>
>> You can also add Exynos4212/4412 to the list.
>>
>>> - reg : Offset and length of the register set for the module
>>> - interrupts : the interrupt-specifier for the SSS module.
>>> Two interrupts "feed control and hash" in case of S5PV210
>>> + One interrupts "feed control" in case of Exynos4210,
>>> + Exynos5250 and Exynos5420 SoCs.
>>
>>
>> You can refer to compatible string here instead of listing all the SoCs.
>>
>>> - clocks : the required gating clock for the SSS module.
>>> - clock-names : the gating clock name to be requested in the SSS driver.
>>
>>
>> Again, please specify name of the clock in property description. The
>> proper description for both clock properties should be:
>>
>> - clock-names : list of device clock input names; should contain one
>> entry - "secss".
>> - clocks : list of clock phandle and specifier pairs for all clocks
>> listed in clock-names property.
>>
>>> +
>>> +Example:
>>> + /* SSS_VER_5 */
>>> + sss@1083 {
>>> + compatible = "samsung,exynos4210-secss";
>>> + reg = <0x1083 0x1>;
>>> + interrupts = <0 112 0>;
>>> + clocks = <&clock 471>;
>>> + clock-names = "secss";
>>> + };
>>> diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
>>> index 2da5617..f274f5f 100644
>>> --- a/drivers/crypto/s5p-sss.c
>>> +++ b/drivers/crypto/s5p-sss.c
>>> @@ -106,7 +106,7 @@
>>> #define SSS_REG_FCPKDMAO 0x005C
>>>
>>> /* AES registers */
>>> -#define SSS_REG_AES_CONTROL 0x4000
>>> +#define SSS_REG_AES_CONTROL 0x00
>>> #define SSS_AES_BYTESWAP_DI _BIT(11)
>>> #define SSS_AES_BYTESWAP_DO _BIT(10)
>>> #define SSS_AES_BYTESWAP_IV _BIT(9)
>>> @@ -122,21 +122,26 @@
>>> #define SSS_AES_CHAIN_MODE_CTR _SBF(1, 0x02)
>>> #define SSS_AES_MODE_DECRYPT _BIT(0)
>>>
>>> -#define SSS_REG_AES_STATUS 0x4004
>>> +#define SSS_REG_AES_STATUS 0x04
>>> #define SSS_AES_BUSY _BIT(2)
>>> #define SSS_AES_INPUT_READY _BIT(1)
>>> #define SSS_AES_OUTPUT_READY _BIT(0)
>>>
>>> -#define SSS_REG_AES_IN_DATA(s) (0x4010 + (s &l

Re: [PATCH 2/6 v2] crypto:s5p-sss: Add device tree support

[Naveen Krishna Ch]

Hello Tomasz,

Thanks for time and review comments they are really helping me a lot
in getting the patches merged.

Secondly, accept my apologies for not giving proper writeup of why i
din't address
few of your comments on v1 of this patchset.

On 9 January 2014 19:44, Tomasz Figa  wrote:
> Hi Naveen,
>
>
> On 09.01.2014 05:59, Naveen Krishna Chatradhi wrote:
>>
>> This patch adds device tree support to the s5p-sss.c crypto driver.
>> Implements a varient struct to address the changes in SSS hardware
>> on various SoCs from Samsung.
>>
>> Also, Documentation under devicetree/bindings added.
>>
>> Signed-off-by: Naveen Krishna Ch 
>> CC: Herbert Xu 
>> CC: David S. Miller 
>> CC: Vladimir Zapolskiy 
>> TO: 
>> CC: 
>> ---
>> Changes since v1:
>> 1. Added description of the SSS module in Documentation
>> 2. Corrected the interrupts description
>> 3. Added varient struct instead of the version variable
>>
>>   .../devicetree/bindings/crypto/samsung-sss.txt |   20 +
>>   drivers/crypto/s5p-sss.c   |   81
>> ++--
>>   2 files changed, 95 insertions(+), 6 deletions(-)
>>   create mode 100644
>> Documentation/devicetree/bindings/crypto/samsung-sss.txt
>>
>> diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
>> b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
>> new file mode 100644
>> index 000..0e45b0d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
>> @@ -0,0 +1,20 @@
>> +Samsung SoC SSS (Security SubSystem) module
>> +
>> +The SSS module in S5PV210 SoC supports the following:
>> +-- Feeder (FeedCtrl)
>> +-- Advanced Encryption Standard (AES)
>> +-- Data Encryption Standard (DES)/3DES
>> +-- Public Key Accelerator (PKA)
>> +-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
>> +-- PRNG: Pseudo Random Number Generator
>> +
>> +Required properties:
>> +
>> +- compatible : Should contain entries for this and backward compatible
>> +  SSS versions:
>> +  - "samsung,s5p-secss" for S5PV210 SoC.
>
>
> As I wrote in my previous reply, please use specific compatible string
> containing name of SoC on which the block described by it appeared first.
> Let me say it again, for security block that showed up first on S5PV210 the
> string will be "samsung,s5pv210-secss".
1. .name   = "s5p-secss", is the name used in the present driver.
So, i dint modify that.
2. I'm not sure which one is the first soc to have the new varient.
May be Exynos4210. Will modify in the next version.

>
>
>> +- reg : Offset and length of the register set for the module
>> +- interrupts : the interrupt-specifier for the SSS module.
>> +   Two interrupts "feed control and hash" in case of S5PV210
>> +- clocks : the required gating clock for the SSS module.
>> +- clock-names : the gating clock name to be requested in the SSS driver.
>> diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
>> index 93cddeb..78e0c37 100644
>> --- a/drivers/crypto/s5p-sss.c
>> +++ b/drivers/crypto/s5p-sss.c
>> @@ -22,6 +22,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>>
>> @@ -145,6 +146,20 @@
>>   #define AES_KEY_LEN 16
>>   #define CRYPTO_QUEUE_LEN1
>>
>> +/**
>> + * struct samsung_aes_varient - platform specific SSS driver data
>
>
> typo: s/varient/variant/g
>
> Anyway, I think this should be moved to the patch adding support for
> Exynos5, as before it there is no use for this struct and it's not directly
> related to DT support.
>
>
>> + * @has_hash_irq: true if SSS module uses hash interrupt, false otherwise
>> + * @aes_offset: AES register offset from SSS module's base.
>> + *
>> + * Specifies platform specific configuration of SSS module.
>> + * Note: A structure for driver specific platform data is used for future
>> + * expansion of its usage.
>> + */
>> +struct samsung_aes_varient {
>> +   boolhas_hash_irq;
>> +   unsigned intaes_offset;
>> +};
>> +
>>   struct s5p_aes_reqctx {
>> unsigned long mode;
>>   };
>> @@ -173,10 +188,56 @@ struct s5p_aes_dev {
>> struct crypto_queue queue;
>> boolbusy;
>> spinlock_t  lock;
>> +
>> +   struct samsung_aes_varient *

Re: [PATCH 4/5] crypto:s5p-sss: Exynos5 SoCs too can select SSS driver

[Naveen Krishna Ch]

Hello Tomasz,

On 8 January 2014 06:00, Tomasz Figa  wrote:
> On Tuesday 07 of January 2014 17:21:48 Naveen Krishna Ch wrote:
>> This patch modifies Kconfig such that ARCH_EXYNOS5 SoCs
>> can also select Samsung SSS(Security SubSystem) driver.
>>
>> Signed-off-by: Naveen Krishna Ch 
>> CC: Herbert Xu 
>> CC: David S. Miller 
>> CC: Vladimir Zapolskiy 
>> TO: 
>> CC: 
>> ---
>>  drivers/crypto/Kconfig |8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
>> index f4fd837..137dcd8 100644
>> --- a/drivers/crypto/Kconfig
>> +++ b/drivers/crypto/Kconfig
>> @@ -300,15 +300,15 @@ config CRYPTO_DEV_DCP
>> capabilities of the DCP co-processor
>>
>>  config CRYPTO_DEV_S5P
>> - tristate "Support for Samsung S5PV210 crypto accelerator"
>> - depends on ARCH_S5PV210
>> + tristate "Support for Samsung crypto accelerator"
>> + depends on ARCH_S5PV210 || ARCH_EXYNOS5
>>   select CRYPTO_AES
>>   select CRYPTO_ALGAPI
>>   select CRYPTO_BLKCIPHER
>>   help
>> This option allows you to have support for S5P crypto acceleration.
>> -   Select this to offload Samsung S5PV210 or S5PC110 from AES
>> -   algorithms execution.
>> +   Select this to offload Samsung S5PV210 or S5PC110, Exynos5250
>> +   and Exynos5420 from AES algorithms execution.
>
> What about Exynos4 SoCs?
The SSS module as such looks alike on Exynos5250, Exynso5420 and Exynos4210.
I couldn't test it right now. I should also verify on other Exynos4 SoCs.
>
> Best regards,
> Tomasz
>



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/5] ARM: exynos5420: add dt node for sss module

[Naveen Krishna Ch]

Hello Tomasz,

On 8 January 2014 06:02, Tomasz Figa  wrote:
> On Tuesday 07 of January 2014 17:21:49 Naveen Krishna Ch wrote:
>> From: Naveen Krishna Chatradhi 
>>
>> this patch adds the device tree nodes for SSS module found on Exynos5420
>
> nit: Sentences in English start with a capital letter. Also this patch
> adds one node, not few of them as the description suggests.
>
> Also patch subject should start with ARM: dts: prefix.
>
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> TO: 
>> CC: Kukjin Kim 
>> CC: 
>> ---
>>  arch/arm/boot/dts/exynos5420.dtsi |   10 ++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
>> b/arch/arm/boot/dts/exynos5420.dtsi
>> index 11dd202..97045f9 100644
>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>> @@ -652,4 +652,14 @@
>>   clocks = <&clock 319>, <&clock 318>;
>>   clock-names = "tmu_apbif", "tmu_triminfo_apbif";
>>   };
>> +
>> + sss: sss {
>
> Node name should be sss@1083 as per ePAPR node naming recommendation.
Thanks for the correction, Will correct it and submit. Thanks
>
> Best regards,
> Tomasz
>



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/5] crypto:s5p-sss: Add DT and Exynos5 support

[Naveen Krishna Ch]

SSS module on Exynos5 SoCs has added features to the one on S5PV210
However minor changes to the s5p-sss.c driver are required to support
SSS modules on Exynos5 SoCs.

This patch set
1. Adds device tree support to the s5p-sss.c driver
2. Adds code to support SSS module on Exynos5 SoCs
3. Adds device tree node to Exynos5420
4. Also adds the DT binding documentation

Naveen Krishna Ch (4): [crypto-2.6.git]
  crypto:s5p-sss: Use platform_get_irq() instead of _byname()
  crypto:s5p-sss: Add device tree and Exynos5 support
  crypto:s5p-sss: Add support for SSS module on Exynos5
  crypto:s5p-sss: Exynos5 SoCs too can select SSS driver

Naveen Krishna Chatradhi (1): [linuxsamsung.git]
  ARM: exynos5420: add dt node for sss module

 .../devicetree/bindings/crypto/samsung-sss.txt |   24 
 arch/arm/boot/dts/exynos5420.dtsi  |   10 ++
 drivers/crypto/Kconfig |8 +-
 drivers/crypto/s5p-sss.c   |  115 +++-
 4 files changed, 127 insertions(+), 30 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/crypto/samsung-sss.txt

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/5] crypto:s5p-sss: Add device tree and Exynos5 support

[Naveen Krishna Ch]

This patch adds device tree support along with a new
compatible string to support Exynos5 SoCs (SSS_VER_5).

Also, Documentation under devicetree/bindings added.

Signed-off-by: Naveen Krishna Ch 
CC: Herbert Xu 
CC: David S. Miller 
CC: Vladimir Zapolskiy 
TO: 
CC: 
---
 .../devicetree/bindings/crypto/samsung-sss.txt |   24 
 drivers/crypto/s5p-sss.c   |   40 
 2 files changed, 64 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/samsung-sss.txt

diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt 
b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
new file mode 100644
index 000..8871a29
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
@@ -0,0 +1,24 @@
+Samsung SoC SSS crypto Module
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+  SSS versions:
+  - "samsung,exynos-secss" for S5PV210.
+  - "samsung,s5p-secss" for Exynos5 series SoCs.
+  TBD: SSS module on Exynos5 SoCs supports other algorithms,
+  support for the is yet to be added in the driver.
+- reg : Offset and length of the register set for the module
+- interrupts : the interrupt-specifier for the SSS module.
+- clocks : the required gating clock for the SSS module.
+- clock-names : the gating clock name requested in the SSS driver.
+
+Example:
+   /* SSS_VER_5 */
+   sss: sss {
+   compatible = "samsung,exynos-secss";
+   reg = <0x1083 0x1>;
+   interrupts = <0 112 0>;
+   clocks = <&clock 471>;
+   clock-names = "secss";
+   };
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index dda4551..dcb9fc1 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -173,10 +174,45 @@ struct s5p_aes_dev {
struct crypto_queue queue;
boolbusy;
spinlock_t  lock;
+
+   /* To support SSS versions across Samsung SoCs */
+   unsigned intversion;
 };
 
 static struct s5p_aes_dev *s5p_dev;
 
+enum sss_version {
+   SSS_VER_4,  /* SSS found on S5PV210 */
+   SSS_VER_5,  /* SSS found on Exynos5 Series SoCs */
+};
+
+static struct platform_device_id s5p_sss_ids[] = {
+   {
+   .name   = "s5p-secss",
+   .driver_data= SSS_VER_4,
+   }, { },
+};
+MODULE_DEVICE_TABLE(platform, s5p_sss_ids);
+
+static struct of_device_id s5p_sss_dt_match[] = {
+   { .compatible = "samsung,s5p-secss", .data = (void *)SSS_VER_4 },
+   { .compatible = "samsung,exynos-secss", .data = (void *)SSS_VER_5 },
+   { },
+};
+MODULE_DEVICE_TABLE(of, s5p_sss_dt_match);
+
+static inline unsigned int find_s5p_sss_version(struct platform_device *pdev)
+{
+#ifdef CONFIG_OF
+   if (pdev->dev.of_node) {
+   const struct of_device_id *match;
+   match = of_match_node(s5p_sss_dt_match, pdev->dev.of_node);
+   return (unsigned int)match->data;
+   }
+#endif
+   return platform_get_device_id(pdev)->driver_data;
+}
+
 static void s5p_set_dma_indata(struct s5p_aes_dev *dev, struct scatterlist *sg)
 {
SSS_WRITE(dev, FCBRDMAS, sg_dma_address(sg));
@@ -580,6 +616,8 @@ static int s5p_aes_probe(struct platform_device *pdev)
 resource_size(res), pdev->name))
return -EBUSY;
 
+   pdata->version = find_s5p_sss_version(pdev);
+
pdata->clk = devm_clk_get(dev, "secss");
if (IS_ERR(pdata->clk)) {
dev_err(dev, "failed to find secss clock source\n");
@@ -674,9 +712,11 @@ static int s5p_aes_remove(struct platform_device *pdev)
 static struct platform_driver s5p_aes_crypto = {
.probe  = s5p_aes_probe,
.remove = s5p_aes_remove,
+   .id_table   = s5p_sss_ids,
.driver = {
.owner  = THIS_MODULE,
.name   = "s5p-secss",
+   .of_match_table = s5p_sss_dt_match,
},
 };
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/5] crypto:s5p-sss: Add support for SSS module on Exynos5

[Naveen Krishna Ch]

The differences between SSS modules on S5PV210 and Exynos5
(AFA the driver supports)
1. AES register are at an offset of 0x200 on Exynos5
2. hash interrupt is no longer needed on Exynos5

This patch adds code needed to address the above changes.

Signed-off-by: Naveen Krishna Ch 
CC: Herbert Xu 
CC: David S. Miller 
CC: Vladimir Zapolskiy 
TO: 
CC: 
---
 drivers/crypto/s5p-sss.c |   59 --
 1 file changed, 41 insertions(+), 18 deletions(-)

diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index dcb9fc1..a11cd0e 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -106,7 +106,7 @@
 #define SSS_REG_FCPKDMAO0x005C
 
 /* AES registers */
-#define SSS_REG_AES_CONTROL 0x4000
+#define SSS_REG_AES_CONTROL(dev)   ((dev)->aes_offset + 0x00)
 #define SSS_AES_BYTESWAP_DI _BIT(11)
 #define SSS_AES_BYTESWAP_DO _BIT(10)
 #define SSS_AES_BYTESWAP_IV _BIT(9)
@@ -122,21 +122,26 @@
 #define SSS_AES_CHAIN_MODE_CTR  _SBF(1, 0x02)
 #define SSS_AES_MODE_DECRYPT_BIT(0)
 
-#define SSS_REG_AES_STATUS  0x4004
+#define SSS_REG_AES_STATUS(dev)((dev)->aes_offset + 0x04)
 #define SSS_AES_BUSY_BIT(2)
 #define SSS_AES_INPUT_READY _BIT(1)
 #define SSS_AES_OUTPUT_READY_BIT(0)
 
-#define SSS_REG_AES_IN_DATA(s)  (0x4010 + (s << 2))
-#define SSS_REG_AES_OUT_DATA(s) (0x4020 + (s << 2))
-#define SSS_REG_AES_IV_DATA(s)  (0x4030 + (s << 2))
-#define SSS_REG_AES_CNT_DATA(s) (0x4040 + (s << 2))
-#define SSS_REG_AES_KEY_DATA(s) (0x4080 + (s << 2))
+#define SSS_REG_AES_IN_DATA(dev, s)((dev)->aes_offset + 0x10 + (s << 2))
+#define SSS_REG_AES_OUT_DATA(dev, s)   ((dev)->aes_offset + 0x20 + (s << 2))
+#define SSS_REG_AES_IV_DATA(dev, s)((dev)->aes_offset + 0x30 + (s << 2))
+#define SSS_REG_AES_CNT_DATA(dev, s)   ((dev)->aes_offset + 0x40 + (s << 2))
+#define SSS_REG_AES_KEY_DATA(dev, s)   ((dev)->aes_offset + 0x80 + (s << 2))
 
 #define SSS_REG(dev, reg)   ((dev)->ioaddr + (SSS_REG_##reg))
 #define SSS_READ(dev, reg)  __raw_readl(SSS_REG(dev, reg))
 #define SSS_WRITE(dev, reg, val)__raw_writel((val), SSS_REG(dev, reg))
 
+#define SSS_AES_REG(dev, reg)  ((dev)->ioaddr + (SSS_REG_##reg(dev)))
+#define SSS_AES_READ(dev, reg)  __raw_readl(SSS_AES_REG(dev, reg))
+#define SSS_AES_WRITE(dev, reg, val)__raw_writel((val),\
+   SSS_AES_REG(dev, reg))
+
 /* HW engine modes */
 #define FLAGS_AES_DECRYPT   _BIT(0)
 #define FLAGS_AES_MODE_MASK _SBF(1, 0x03)
@@ -177,6 +182,13 @@ struct s5p_aes_dev {
 
/* To support SSS versions across Samsung SoCs */
unsigned intversion;
+
+   /*
+* Register banks corresponding to various algorithms
+* (Ex: AES, TDES, HASH, TRNG, PKA etc.)
+* are at an offsets from the base (depending on SSS verion)
+*/
+   unsigned intaes_offset;
 };
 
 static struct s5p_aes_dev *s5p_dev;
@@ -358,14 +370,14 @@ static void s5p_set_aes(struct s5p_aes_dev *dev,
 {
void __iomem *keystart;
 
-   memcpy(dev->ioaddr + SSS_REG_AES_IV_DATA(0), iv, 0x10);
+   memcpy(dev->ioaddr + SSS_REG_AES_IV_DATA(dev, 0), iv, 0x10);
 
if (keylen == AES_KEYSIZE_256)
-   keystart = dev->ioaddr + SSS_REG_AES_KEY_DATA(0);
+   keystart = dev->ioaddr + SSS_REG_AES_KEY_DATA(dev, 0);
else if (keylen == AES_KEYSIZE_192)
-   keystart = dev->ioaddr + SSS_REG_AES_KEY_DATA(2);
+   keystart = dev->ioaddr + SSS_REG_AES_KEY_DATA(dev, 2);
else
-   keystart = dev->ioaddr + SSS_REG_AES_KEY_DATA(4);
+   keystart = dev->ioaddr + SSS_REG_AES_KEY_DATA(dev, 4);
 
memcpy(keystart, key, keylen);
 }
@@ -415,7 +427,7 @@ static void s5p_aes_crypt_start(struct s5p_aes_dev *dev, 
unsigned long mode)
if (err)
goto outdata_error;
 
-   SSS_WRITE(dev, AES_CONTROL, aes_control);
+   SSS_AES_WRITE(dev, AES_CONTROL, aes_control);
s5p_set_aes(dev, dev->ctx->aes_key, req->info, dev->ctx->keylen);
 
s5p_set_dma_indata(dev,  req->src);
@@ -618,6 +630,11 @@ static int s5p_aes_probe(struct platform_device *pdev)
 
pdata->version = find_s5p_sss_version(pdev);
 
+   if (pdata->version == SSS_VER_5)
+   pdata->aes_offset = 0x200;
+   else
+   pdata->aes_offset = 0x4000;
+
pdata->clk = devm_clk_get(dev, "secss");
if (IS_ERR(pdata->clk)) {
dev_err(dev, "failed to find secss clock source\n");
@@ -643,17 +660,23 @@ static in

[PATCH 5/5] ARM: exynos5420: add dt node for sss module

[Naveen Krishna Ch]

From: Naveen Krishna Chatradhi 

this patch adds the device tree nodes for SSS module found on Exynos5420

Signed-off-by: Naveen Krishna Chatradhi 
TO: 
CC: Kukjin Kim 
CC: 
---
 arch/arm/boot/dts/exynos5420.dtsi |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 11dd202..97045f9 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -652,4 +652,14 @@
clocks = <&clock 319>, <&clock 318>;
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
};
+
+   sss: sss {
+   compatible = "samsung,exynos-secss";
+   reg = <0x1083 0x1>;
+   interrupts = <0 112 0>;
+   clocks = <&clock 471>;
+   clock-names = "secss";
+   samsung,power-domain = <&g2d_pd>;
+   };
+
 };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/5] crypto:s5p-sss: Exynos5 SoCs too can select SSS driver

[Naveen Krishna Ch]

This patch modifies Kconfig such that ARCH_EXYNOS5 SoCs
can also select Samsung SSS(Security SubSystem) driver.

Signed-off-by: Naveen Krishna Ch 
CC: Herbert Xu 
CC: David S. Miller 
CC: Vladimir Zapolskiy 
TO: 
CC: 
---
 drivers/crypto/Kconfig |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index f4fd837..137dcd8 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -300,15 +300,15 @@ config CRYPTO_DEV_DCP
  capabilities of the DCP co-processor
 
 config CRYPTO_DEV_S5P
-   tristate "Support for Samsung S5PV210 crypto accelerator"
-   depends on ARCH_S5PV210
+   tristate "Support for Samsung crypto accelerator"
+   depends on ARCH_S5PV210 || ARCH_EXYNOS5
select CRYPTO_AES
select CRYPTO_ALGAPI
select CRYPTO_BLKCIPHER
help
  This option allows you to have support for S5P crypto acceleration.
- Select this to offload Samsung S5PV210 or S5PC110 from AES
- algorithms execution.
+ Select this to offload Samsung S5PV210 or S5PC110, Exynos5250
+ and Exynos5420 from AES algorithms execution.
 
 config CRYPTO_DEV_TEGRA_AES
tristate "Support for TEGRA AES hw engine"
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/5] crypto:s5p-sss: Use platform_get_irq() instead of _byname()

[Naveen Krishna Ch]

This patch uses the platform_get_irq() instead of the
platform_get_irq_byname(). Making feeder control interrupt
as resource "0" and hash interrupt as "1".

reasons for this change.
1. Cannot find any Arch which is currently using this driver
2. Samsung Exynos5 SoCs only use the feeder control interrupt
3. Patches adding support for DT and H/W version are in pipeline

Signed-off-by: Naveen Krishna Ch 
CC: Herbert Xu 
CC: David S. Miller 
CC: Vladimir Zapolskiy 
TO: 
CC: 
---
 drivers/crypto/s5p-sss.c |   22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index cf149b1..dda4551 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -592,29 +592,29 @@ static int s5p_aes_probe(struct platform_device *pdev)
pdata->ioaddr = devm_ioremap(dev, res->start,
 resource_size(res));
 
-   pdata->irq_hash = platform_get_irq_byname(pdev, "hash");
-   if (pdata->irq_hash < 0) {
+   pdata->irq_fc = platform_get_irq(pdev, 0);
+   if (pdata->irq_fc < 0) {
err = pdata->irq_hash;
-   dev_warn(dev, "hash interrupt is not available.\n");
+   dev_warn(dev, "feed control interrupt is not available.\n");
goto err_irq;
}
-   err = devm_request_irq(dev, pdata->irq_hash, s5p_aes_interrupt,
+   err = devm_request_irq(dev, pdata->irq_fc, s5p_aes_interrupt,
   IRQF_SHARED, pdev->name, pdev);
if (err < 0) {
-   dev_warn(dev, "hash interrupt is not available.\n");
+   dev_warn(dev, "feed control interrupt is not available.\n");
goto err_irq;
}
 
-   pdata->irq_fc = platform_get_irq_byname(pdev, "feed control");
-   if (pdata->irq_fc < 0) {
-   err = pdata->irq_fc;
-   dev_warn(dev, "feed control interrupt is not available.\n");
+   pdata->irq_hash = platform_get_irq(pdev, 1);
+   if (pdata->irq_hash < 0) {
+   err = pdata->irq_hash;
+   dev_warn(dev, "hash interrupt is not available.\n");
goto err_irq;
}
-   err = devm_request_irq(dev, pdata->irq_fc, s5p_aes_interrupt,
+   err = devm_request_irq(dev, pdata->irq_hash, s5p_aes_interrupt,
   IRQF_SHARED, pdev->name, pdev);
if (err < 0) {
-   dev_warn(dev, "feed control interrupt is not available.\n");
+   dev_warn(dev, "hash interrupt is not available.\n");
goto err_irq;
}
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v11 3/4] thermal: samsung: Add TMU support for Exynos5420 SoCs

[Naveen Krishna Ch]

Hello Tomasz,


On 18 December 2013 21:20, Tomasz Figa  wrote:
> Hi Naveen,
>
> On Tuesday 10 of December 2013 12:12:25 Naveen Krishna Chatradhi wrote:
>> Exynos5420 has 5 TMU channels, the TRIMINFO register is
>> misplaced for TMU channels 2, 3 and 4
>> TRIMINFO at 0x1006c000 contains data for TMU channel 3
>> TRIMINFO at 0x100a contains data for TMU channel 4
>> TRIMINFO at 0x10068000 contains data for TMU channel 2
> [snip]
>> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
>> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> index a1aa602..a3e78c0 100644
>> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> @@ -6,6 +6,9 @@
>>  "samsung,exynos4412-tmu"
>>  "samsung,exynos4210-tmu"
>>  "samsung,exynos5250-tmu"
>> +"samsung,exynos5420-tmu" for TMU channel 0, 1 on Exynos5420
>> +"samsung,exynos5420-tmu-ext-triminfo" for TMU channels 2, 3 and 
>> 4
>> + Exynos5420 (Must pass triminfo base and triminfo clock)
>
> Exact clock names must be specified in description of clock-names property.
Sure, will add them.
>
>>  "samsung,exynos5440-tmu"
>>  - interrupt-parent : The phandle for the interrupt controller
>>  - reg : Address range of the thermal registers. For soc's which has multiple
>> @@ -13,6 +16,16 @@
>>   interrupt related then 2 set of register has to supplied. First set
>>   belongs to register set of TMU instance and second set belongs to
>>   registers shared with the TMU instance.
>> +
>> +  NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
>> + channels 2, 3 and 4
>> + Use "samsung,exynos5420-tmu-ext-triminfo" in cases, there is a 
>> misplaced
>> + register, also provide clock to access that base.
>> +
>> + TRIMINFO at 0x1006c000 contains data for TMU channel 3
>> + TRIMINFO at 0x100a contains data for TMU channel 4
>> + TRIMINFO at 0x10068000 contains data for TMU channel 2
>> +
>>  - interrupts : Should contain interrupt for thermal system
>>  - clocks : The main clock for TMU device
>>  - clock-names : Thermal system clock name
>> @@ -43,6 +56,31 @@ Example 2):
>>   clock-names = "tmu_apbif";
>>   };
>>
>> +Example 3): (In case of Exynos5420 "with misplaced TRIMINFO register")
>> + tmu_cpu2: tmu@10068000 {
>> + compatible = "samsung,exynos5420-tmu-ext-triminfo";
>> + reg = <0x10068000 0x100>, <0x1006c000 0x4>;
>> + interrupts = <0 184 0>;
>> + clocks = <&clock 318>, <&clock 318>;
>> + clock-names = "tmu_apbif", "tmu_triminfo_apbif";
>
> Here you have "tmu_triminfo_apbif" clock, but in the driver you call
> clk_get() with "tmu_apbif_triminfo".
My bad, will correct this
>
>> + };
>> +
> [snip]
>>
>> + data->clk_sec = devm_clk_get(&pdev->dev, "tmu_apbif_triminfo");
>
> Here you try to get "tmu_apbif_triminfo" clock, but in binding
> documentation you have "tmu_triminfo_apbif" in example.
My bad, will correct this
>
>> + if (IS_ERR(data->clk_sec)) {
>> + if (data->soc == SOC_ARCH_EXYNOS5420_TRIMINFO) {
>> + dev_err(&pdev->dev, "Failed to get triminfo clock\n");
>> + return PTR_ERR(data->clk_sec);
>> + }
>> + } else {
>> + ret = clk_prepare(data->clk_sec);
>> + if (ret) {
>> + dev_err(&pdev->dev, "Failed to get clock\n");
>> + return ret;
>> + }
>> + }
>> +
>>   ret = clk_prepare(data->clk);
>> - if (ret)
>> - return ret;
>> + if (ret) {
>> + dev_err(&pdev->dev, "Failed to get clock\n");
>> + goto err_clk_sec;
>> + }
>>
>>   if (pdata->type == SOC_ARCH_EXYNOS4210 ||
>>   pdata->type == SOC_ARCH_EXYNOS4412 ||
>>   pdata->type == SOC_ARCH_EXYNOS5250 ||
>> + pdata->type == SOC_ARCH_EXYNOS5420_TRIMINFO ||
TMU channel 0, 1 on Exynos5420 does not require a new pdata->type.
The are exactly similar to Exynos5250. Only the channels 2, 3 and 4
have the triminfo register misplaced.

Hence, just SOC_ARCH_EXYNOS5420_TRIMINFO should be enough

>
> Don't you also need SOC_ARCH_EXYNOS5420 here?
>
>>   pdata->type == SOC_ARCH_EXYNOS5440)
>>   data->soc = pdata->type;
>>   else {
>> @@ -703,6 +742,9 @@ static int exynos_tmu_probe(struct platform_device *pdev)
>>   return 0;
>>  err_clk:
>>   clk_unprepare(data->clk);
>> +err_clk_sec:
>> + if (!IS_ERR(data->clk_sec))
>> + clk_unprepare(data->clk_sec);
>>   return ret;
>>  }
>>
>> @@ -715,6 +757,8 @@ static int exynos_tmu_remove(struct platform_device 
>> *pdev)
>>   exynos_unregister_thermal(data->reg_conf);
>>
>>   clk_unprepare(data->clk);
>> + if (!IS_ERR(data->clk_sec))
>> + clk_unprepare(data->clk_

Re: [PATCH 2/2] i2c: exynos5: configure fifo_depth based on HSI2C module version

[Naveen Krishna Ch]

Hello Tomasz,


On 9 December 2013 22:01, Tomasz Figa  wrote:
>
> Hi Naveen,
>
> On Friday 22 of November 2013 11:44:11 Naveen Krishna Chatradhi wrote:
> > fifo_depth of the HSI2C is not constant
> > Exynos5420 and Exynos5250 supports fifo_depth of 64bytes
> > Exynos5260 supports fifo_depth of 16bytes
> >
> > This patch configures the fifo_depth based on HSI2C modules version.
> > Signed-off-by: Naveen Krishna Chatradhi 
> > ---
> >  drivers/i2c/busses/i2c-exynos5.c |   29 ++---
> >  1 file changed, 18 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-exynos5.c 
> > b/drivers/i2c/busses/i2c-exynos5.c
> > index cbb49e2..19277d8 100644
> > --- a/drivers/i2c/busses/i2c-exynos5.c
> > +++ b/drivers/i2c/busses/i2c-exynos5.c
> > @@ -77,12 +77,6 @@
> >  #define HSI2C_RXFIFO_TRIGGER_LEVEL(x)((x) << 4)
> >  #define HSI2C_TXFIFO_TRIGGER_LEVEL(x)((x) << 16)
> >
> > -/* As per user manual FIFO max depth is 64bytes */
> > -#define HSI2C_FIFO_MAX   0x40
> > -/* default trigger levels for Tx and Rx FIFOs */
> > -#define HSI2C_DEF_TXFIFO_LVL (HSI2C_FIFO_MAX - 0x30)
> > -#define HSI2C_DEF_RXFIFO_LVL (HSI2C_FIFO_MAX - 0x10)
> > -
> >  /* I2C_TRAILING_CTL Register bits */
> >  #define HSI2C_TRAILING_COUNT (0xf)
> >
> > @@ -187,6 +181,9 @@ struct exynos5_i2c {
> >
> >   /* Version of HS-I2C Hardware */
> >   unsigned intversion;
> > +
> > + /* FIFO depth */
> > + unsigned intfifo_depth;
> >  };
> >
> >  enum hsi2c_version {
> > @@ -437,7 +434,7 @@ static irqreturn_t exynos5_i2c_irq(int irqno, void 
> > *dev_id)
> >   fifo_status = readl(i2c->regs + HSI2C_FIFO_STATUS);
> >   fifo_level = HSI2C_TX_FIFO_LVL(fifo_status);
> >
> > - len = HSI2C_FIFO_MAX - fifo_level;
> > + len = i2c->fifo_depth - fifo_level;
> >   if (len > (i2c->msg->len - i2c->msg_ptr))
> >   len = i2c->msg->len - i2c->msg_ptr;
> >
> > @@ -505,6 +502,7 @@ static void exynos5_i2c_message_start(struct 
> > exynos5_i2c *i2c, int stop)
> >   u32 i2c_auto_conf = 0;
> >   u32 fifo_ctl;
> >   unsigned long flags;
> > + unsigned short trig_lvl;
> >
> >   i2c_ctl = readl(i2c->regs + HSI2C_CTL);
> >   i2c_ctl &= ~(HSI2C_TXCHON | HSI2C_RXCHON);
> > @@ -515,13 +513,19 @@ static void exynos5_i2c_message_start(struct 
> > exynos5_i2c *i2c, int stop)
> >
> >   i2c_auto_conf = HSI2C_READ_WRITE;
> >
> > - fifo_ctl |= HSI2C_RXFIFO_TRIGGER_LEVEL(HSI2C_DEF_TXFIFO_LVL);
> > + trig_lvl = (i2c->msg->len > i2c->fifo_depth) ?
> > + (i2c->fifo_depth * 3/4) : i2c->msg->len;
>
> This patch changes the fifo trigger level calculation (it's dependent now
> on message length), not just maximum fifo size, as the description says.
Actually, message->length need not be involved in this calculation.
Involving msg->len
will raise another interrupt for every small transactions. It better be avoided.
> It should be split into two separate patches, explaining why both changes
> are necessary.
I will split the fifo_depth configuration code along with comments addressed on
https://lkml.org/lkml/2013/11/22/31

I can think of 3 ways to address the h/w version changes
1. Compatible string as i implemented
2. Varient struct
3. Passing the information via device tree
How about passing fifo_depth from device tree information.

Currently, HSI2C Module on Exynso5260 is not another H/W version.
It only defer in fifo_depth and init sequence needs a reset.

>
>
> Best regards,
> Tomasz
>



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2 v2] i2c: exynos5: add support for HSI2C on Exynos5260 SoC

[Naveen Krishna Ch]

Hello Sachin,

On 26 November 2013 16:59, Sachin Kamat  wrote:
> On 26 November 2013 09:56, Naveen Krishna Chatradhi
>  wrote:
>> This patch adds new compatible to support HSI2C module on Exynos5260
>> HSI2C module on Exynos5260 needs to be reset during during initialization.
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
> [snip]
>>
>>  Required properties:
>>- compatible: value should be.
>> -  -> "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
>> +   -> "samsung,exynos5-hsi2c", for i2c compatible with HSI2C available 
>> on
>> +   Exynos5250/5420 SoCs.
The first HSI2C module is available on Exynos5 SoCs from Samsung.
Hence, "samsung,exynos5-hsi2c"
HSI2C Module on  Exynos5250 and Exynos5420 was exactly similar

HSI2C Module on Exynos5260 differs in hardware.
Hence, "samsung,exynos5260-hsi2c".

And as the new variants come we use "samsung,exynosXXX-hsi2c"
or we can go by "samsung,exynos5-hsi2c-v2"

Changing an existing compatible needs modification in the DT nodes as well.

I will change the compatible string, if anyone else also thinks its wise.
>
> This string could be made more specific ("samsung,exynos5250-hsi2c")
> now that we have variants for this.
>
>> +   -> "samsung,exynos5260-hsi2c", for i2c compatible with HSI2C 
>> available
>> +   on Exynos5260 SoCs.
>> +
>>- reg: physical base address of the controller and length of memory mapped
>>  region.
>>- interrupts: interrupt number to the cpu.
>> diff --git a/drivers/i2c/busses/i2c-exynos5.c 
>> b/drivers/i2c/busses/i2c-exynos5.c
>> index da39ff0..497ff91 100644
>> --- a/drivers/i2c/busses/i2c-exynos5.c
>> +++ b/drivers/i2c/busses/i2c-exynos5.c
>> @@ -184,14 +184,35 @@ struct exynos5_i2c {
>>  * 2. Fast speed upto 1Mbps
>>  */
>> int speed_mode;
>> +
>> +   /* Version of HS-I2C Hardware */
>> +   unsigned intversion;
>> +};
>> +
>> +enum hsi2c_version {
>> +   EXYNOS_5,
>
> ditto.
>
>> +   EXYNOS_5260
>>  };
>>
>
> --
> With warm regards,
> Sachin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series

[Naveen Krishna Ch]

Hello Doug,

On 26 November 2013 05:11, Doug Anderson  wrote:
> Naveen,
>
> On Mon, Nov 18, 2013 at 10:18 PM, Naveen Krishna Chatradhi
>  wrote:
>> For Exynos4 and Exynos5 SoCs from Samsung the i2c clock is based
>> on a fixed 66 MHz peripheral clock, and therefore is completely
>> independent of the cpu frequency.
>> Thus, registering for a CPU freq notifier is very wasteful.
>>
>> This patch modifes the code such that, i2c bus registers to
>> cpu_freq_transition only if CONFIG_CPU_FREQ_S3C24XX is enabled.
>>
>> This change should save a bunch of cpufreq transitions calls
>> which does not apply to exynos SoCs.
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> Acked-by: Kyungmin Park 
>> Reviewed-by: Doug Anderson 
>> ---
>> Changes since v2:
>> None, Rebased on for-next of linux-i2c git repo.
>>
>> Changes since v1:
>> Use CONFIG_CPU_FREQ_S3C24XX instead of (CONFIG_CPU_FREQ & !CONFIG_EXYNOS)
>> As commented by Tomasz
>>
>>  drivers/i2c/busses/i2c-s3c2410.c |4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> Can you please spin this with comments from
> ?  Thanks!
Thanks for pointing out for me

To summarize, Post f023f8dd59 commit we should be using
ARM_S3C24XX_CPUFREQ instead of ARM_S3C24XX_CPUFREQ right.

Will re-spin with this changes.
>
> -Doug
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks & Regards,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/4 v10] thermal: samsung: Add TMU support for Exynos5420 SoCs

[Naveen Krishna Ch]

Hello All,

On 19 November 2013 18:35, Naveen Krishna Chatradhi
 wrote:
> Exynos5420 has 5 TMU channels, the TRIMINFO register is
> misplaced for TMU channels 2, 3 and 4
> TRIMINFO at 0x1006c000 contains data for TMU channel 3
> TRIMINFO at 0x100a contains data for TMU channel 4
> TRIMINFO at 0x10068000 contains data for TMU channel 2
>
> This patch
> 1 Adds the neccessary register changes and arch information
>to support Exynos5420 SoCs.
> 2. Handles the gate clock for misplaced TRIMINFO register
> 3. Updates the Documentation at
>Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>
> Signed-off-by: Naveen Krishna Chatradhi 
> Signed-off-by: Andrew Bresticker 
> Acked-by: Amit Daniel Kachhap 
> Reviewed-by: Bartlomiej Zolnierkiewicz 
> ---
> Changes since v9:
> Just respinning
>
> Changes since v8:
> 1. rewrote the Documentation for device tree bindings
> 2. Merged the https://lkml.org/lkml/2013/11/7/262 (as this is a fix)
> 3. introduces "samsung,exynos5420-tmu-triminfo" and
>"samsung,exynos5420-tmu-triminfo-clk" to handle the TMU channels on
>Exynos5420 more appropriately
>
>  .../devicetree/bindings/thermal/exynos-thermal.txt |   45 +
>  drivers/thermal/samsung/exynos_tmu.c   |   58 ++-
>  drivers/thermal/samsung/exynos_tmu.h   |2 +
>  drivers/thermal/samsung/exynos_tmu_data.c  |  106 
> 
>  drivers/thermal/samsung/exynos_tmu_data.h  |8 ++
>  5 files changed, 215 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> index 116cca0..5055b31 100644
> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> @@ -6,6 +6,11 @@
>"samsung,exynos4412-tmu"
>"samsung,exynos4210-tmu"
>"samsung,exynos5250-tmu"
> +  "samsung,exynos5420-tmu" for TMU channel 0, 1 on Exynos5420
> +  "samsung,exynos5420-tmu-triminfo" for TMU channel 2 Exynos5420
> +   (Must pass triminfo base)
> +  "samsung,exynos5420-tmu-triminfo-clk" for TMU channel 3 and 4
> +   Exynos5420 (Must pass triminfo base and triminfo 
> clock)
>"samsung,exynos5440-tmu"
>  - interrupt-parent : The phandle for the interrupt controller
>  - reg : Address range of the thermal registers. For soc's which has multiple
> @@ -13,6 +18,18 @@
> interrupt related then 2 set of register has to supplied. First set
> belongs to each instance of TMU and second set belongs to second set
> of common TMU registers.
> +
> +  NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
> +   channels 2, 3 and 4
> +   Use "samsung,exynos5420-tmu-triminfo" in cases, there is a misplaced
> +   register but no need of another clock to access that base.
> +   Use "samsung,exynos5420-tmu-triminfo-clk" in cases where there is a 
> misplaced
> +   register and we need another clock to access that base.
> +
> +   TRIMINFO at 0x1006c000 contains data for TMU channel 3
> +   TRIMINFO at 0x100a contains data for TMU channel 4
> +   TRIMINFO at 0x10068000 contains data for TMU channel 2
> +
>  - interrupts : Should contain interrupt for thermal system
>  - clocks : The main clock for TMU device
>  - clock-names : Thermal system clock name
> @@ -43,6 +60,34 @@ Example 2):
> clock-names = "tmu_apbif";
> };
>
> +Example 3): (In case of Exynos5420 "with misplaced TRIMINFO register")
> +   /* tmu for CPU2 */
> +   tmu@10068000 {
> +   compatible = "samsung,exynos5420-tmu-triminfo";
> +   reg = <0x10068000 0x100>, <0x1006c000 0x4>;
> +   interrupts = <0 184 0>;
> +   clocks = <&clock 318>;
> +   clock-names = "tmu_apbif";
> +   };
> +
> +   /* tmu for CPU3 */
> +   tmu@1006c000 {
> +   compatible = "samsung,exynos5420-tmu-triminfo-clk";
> +   reg = <0x1006c000 0x100>, <0x100a 0x4>;
> +   interrupts = <0 185 0>;
> +   clocks = <&clock 318>;
> +   clock-names = "tmu_apbif", "tmu_triminfo_apbif";
> +   };
> +
> +   /* tmu for GPU */
> +   tmu@100a {
> +   compatible = "samsung,exynos5420-tmu-triminfo-clk";
> +   reg = <0x100a 0x100>, <0x10068000 0x4>;
> +   interrupts = <0 215 0>;
> +   clocks = <&clock 318>;
> +   clock-names = "tmu_apbif", "tmu_triminfo_apbif";
> +   };
> +
>  Note: For multi-instance tmu each instance should have an alias correctly
>  numbered in "aliases" node.
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index bbd0fc3..826647c 100644
> --- a/drivers/thermal/samsung/exyn

Re: [PATCH 2/4 v10] thermal: samsung: change base_common to more meaningful base_second

[Naveen Krishna Ch]

Hello All,

On 19 November 2013 18:34, Naveen Krishna Chatradhi
 wrote:
> On Exynos5440 and Exynos5420 there are registers common
> across the TMU channels.
>
> To support that, we introduced a ADDRESS_MULTIPLE flag in the
> driver and the 2nd set of register base and size are provided
> in the "reg" property of the node.
>
> As per Amit's suggestion, this patch changes the base_common
> to base_second and SHARED_MEMORY to ADDRESS_MULTIPLE.
>
> Signed-off-by: Naveen Krishna Chatradhi 
> Acked-by: Amit Daniel Kachhap 
> Reviewed-by: Bartlomiej Zolnierkiewicz 
> ---
> Changes since v9:
> Just respinning
>
> Changes since v8:
>  None
>  .../devicetree/bindings/thermal/exynos-thermal.txt   |4 ++--
>  drivers/thermal/samsung/exynos_tmu.c |   14 
> +++---
>  drivers/thermal/samsung/exynos_tmu.h |4 ++--
>  drivers/thermal/samsung/exynos_tmu_data.c|2 +-
>  4 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> index 284f530..116cca0 100644
> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> @@ -11,8 +11,8 @@
>  - reg : Address range of the thermal registers. For soc's which has multiple
> instances of TMU and some registers are shared across all TMU's like
> interrupt related then 2 set of register has to supplied. First set
> -   belongs to each instance of TMU and second set belongs to common TMU
> -   registers.
> +   belongs to each instance of TMU and second set belongs to second set
> +   of common TMU registers.
>  - interrupts : Should contain interrupt for thermal system
>  - clocks : The main clock for TMU device
>  - clock-names : Thermal system clock name
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index c493245..bbd0fc3 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -41,7 +41,7 @@
>   * @id: identifier of the one instance of the TMU controller.
>   * @pdata: pointer to the tmu platform/configuration data
>   * @base: base address of the single instance of the TMU controller.
> - * @base_common: base address of the common registers of the TMU controller.
> + * @base_second: base address of the common registers of the TMU controller.
>   * @irq: irq number of the TMU controller.
>   * @soc: id of the SOC type.
>   * @irq_work: pointer to the irq work structure.
> @@ -56,7 +56,7 @@ struct exynos_tmu_data {
> int id;
> struct exynos_tmu_platform_data *pdata;
> void __iomem *base;
> -   void __iomem *base_common;
> +   void __iomem *base_second;
> int irq;
> enum soc_type soc;
> struct work_struct irq_work;
> @@ -297,7 +297,7 @@ skip_calib_data:
> }
> /*Clear the PMIN in the common TMU register*/
> if (reg->tmu_pmin && !data->id)
> -   writel(0, data->base_common + reg->tmu_pmin);
> +   writel(0, data->base_second + reg->tmu_pmin);
>  out:
> clk_disable(data->clk);
> mutex_unlock(&data->lock);
> @@ -454,7 +454,7 @@ static void exynos_tmu_work(struct work_struct *work)
>
> /* Find which sensor generated this interrupt */
> if (reg->tmu_irqstatus) {
> -   val_type = readl(data->base_common + reg->tmu_irqstatus);
> +   val_type = readl(data->base_second + reg->tmu_irqstatus);
> if (!((val_type >> data->id) & 0x1))
> goto out;
> }
> @@ -579,7 +579,7 @@ static int exynos_map_dt_data(struct platform_device 
> *pdev)
>  * Check if the TMU shares some registers and then try to map the
>  * memory of common registers.
>  */
> -   if (!TMU_SUPPORTS(pdata, SHARED_MEMORY))
> +   if (!TMU_SUPPORTS(pdata, ADDRESS_MULTIPLE))
> return 0;
>
> if (of_address_to_resource(pdev->dev.of_node, 1, &res)) {
> @@ -587,9 +587,9 @@ static int exynos_map_dt_data(struct platform_device 
> *pdev)
> return -ENODEV;
> }
>
> -   data->base_common = devm_ioremap(&pdev->dev, res.start,
> +   data->base_second = devm_ioremap(&pdev->dev, res.start,
> resource_size(&res));
> -   if (!data->base_common) {
> +   if (!data->base_second) {
> dev_err(&pdev->dev, "Failed to ioremap memory\n");
> return -ENOMEM;
> }
> diff --git a/drivers/thermal/samsung/exynos_tmu.h 
> b/drivers/thermal/samsung/exynos_tmu.h
> index 980859a..0d6b32f 100644
> --- a/drivers/thermal/samsung/exynos_tmu.h
> +++ b/drivers/thermal/samsung/exynos_tmu.h
> @@ -60,7 +60,7 @@ enum soc_type {
>   * state(active/idle) can be checked.
>   * TMU_S

Re: [PATCH 1/2] i2c: exynos5: add support for HSI2C on Exynos5260 SoC

[Naveen Krishna Ch]

Hello Yuvaraj,

On 22 November 2013 12:16, Yuvaraj Cd  wrote:
> On Fri, Nov 22, 2013 at 11:42 AM, Naveen Krishna Chatradhi
>  wrote:
>> This patch adds new compatible to support HSI2C module on Exynos5260
>> HSI2C module on Exynos5260 needs to be reset during during initialization.
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> ---
>>  .../devicetree/bindings/i2c/i2c-exynos5.txt|6 +++-
>>  drivers/i2c/busses/i2c-exynos5.c   |   31 
>> ++--
>>  2 files changed, 34 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt 
>> b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
>> index 056732c..704ab92 100644
>> --- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
>> +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
>> @@ -5,7 +5,11 @@ at various speeds ranging from 100khz to 3.4Mhz.
>>
>>  Required properties:
>>- compatible: value should be.
>> -  -> "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
>> +   -> "samsung,exynos5-hsi2c", for i2c compatible with HSI2C available 
>> on
>> +   Exynos5250/5420 SoCs.
>> +   -> "samsung,exynos5260-hsi2c", for i2c compatible with HSI2C 
>> available
>> +   on Exynos5260 SoCs.
>> +
>>- reg: physical base address of the controller and length of memory mapped
>>  region.
>>- interrupts: interrupt number to the cpu.
>> diff --git a/drivers/i2c/busses/i2c-exynos5.c 
>> b/drivers/i2c/busses/i2c-exynos5.c
>> index aca3991..cbb49e2 100644
>> --- a/drivers/i2c/busses/i2c-exynos5.c
>> +++ b/drivers/i2c/busses/i2c-exynos5.c
>> @@ -184,14 +184,35 @@ struct exynos5_i2c {
>>  * 2. Fast speed upto 1Mbps
>>  */
>> int speed_mode;
>> +
>> +   /* Version of HS-I2C Hardware */
>> +   unsigned intversion;
>> +};
>> +
>> +enum hsi2c_version {
>> +   EXYNOS_5,
>> +   EXYNOS_5260
>>  };
>>
>>  static const struct of_device_id exynos5_i2c_match[] = {
>> -   { .compatible = "samsung,exynos5-hsi2c" },
>> +   {
>> +   .compatible = "samsung,exynos5-hsi2c",
>> +   .data = (void *)EXYNOS_5 },
>> +   {
>> +   .compatible = "samsung,exynos5260-hsi2c",
>> +   .data = (void *)EXYNOS_5260 },
>> {},
>>  };
>>  MODULE_DEVICE_TABLE(of, exynos5_i2c_match);
>>
>> +static inline unsigned int exynos5_i2c_get_version(struct platform_device 
>> *pdev)
>> +{
>> +   const struct of_device_id *match;
>> +
>> +   match = of_match_node(exynos5_i2c_match, pdev->dev.of_node);
>> +   return (unsigned int)match->data;
>> +}
>> +
>>  static void exynos5_i2c_clr_pend_irq(struct exynos5_i2c *i2c)
>>  {
>> writel(readl(i2c->regs + HSI2C_INT_STATUS),
>> @@ -692,7 +713,13 @@ static int exynos5_i2c_probe(struct platform_device 
>> *pdev)
>> if (ret)
>> goto err_clk;
>>
>> -   exynos5_i2c_init(i2c);
>> +   i2c->version = exynos5_i2c_get_version(pdev);
>> +
>> +   /* The HS-I2C core on Exynos5260 needs a reset to start with */
>> +   if (i2c->version == EXYNOS_5260)
>
> Is there is any change in the HSI2C IP for EXYNOS5260?
> Can you let me know whats the change w.r.t IP and
> why it needs reset to start,which was not needed in earlier SOC?

Problem:
While working on HSI2C on uboot for Exynos5260 i faced a problem.
To operate on bus "0" which was default bus
If i try i2c md/mw on channel 0 without selecting the bus using "i2c dev 0"
the transaction was failing. But, the subsequent transactions were passing.

Software Work around:
After looking at the code i found out, resetting the bus for the first
time made it work.

Hardware engg suggestion:
Meanwhile inputs from Hardware engineers are, "HSI2C on Exynos5260 needs a reset
during init."  I've not gone personally into the internals of HSI2C module.

>From user manual for Exynos5260, FIFO depth supported is 16bytes
instead of 64bytes.
>
>> +   exynos5_i2c_reset(i2c);
>> +   else
>> +   exynos5_i2c_init(i2c);
>>
>> ret = i2c_add_adapter(&i2c->adap);
>> if (ret < 0) {
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] thermal: samsung: Clean up and add support for Exynos5420

[Naveen Krishna Ch]

Hello All,

On 12 November 2013 12:05, Naveen Krishna Chatradhi
 wrote:
> This patchset does a little clean up of the existing code
> 1.  [v9] thermal: samsung: replace inten_ bit fields with intclr_
> 2.  [v9] thermal: samsung: change base_common to more meaningful base_second
>
> adds support for Exynos5420 in the driver and
> 3.  [v9] thermal: samsung: Add TMU support for Exynos5420 SoCs
> also adds the device tree nodes for the same to exynos5420.dtsi 
> (linux-samsung.git)
> 4.  [v3] ARM: dts: Exynos5420: Add device nodes for TMU blocks
>
> Naveen Krishna Chatradhi (3):
>   thermal: samsung: replace inten_ bit fields with intclr_
>   thermal: samsung: change base_common to more meaningful base_second
>   thermal: samsung: Add TMU support for Exynos5420 SoCs
>   ARM: dts: Exynos5420: Add device nodes for TMU blocks
>
>  .../devicetree/bindings/thermal/exynos-thermal.txt |   49 +++-
>  drivers/thermal/samsung/exynos_tmu.c   |   78 +---
>  drivers/thermal/samsung/exynos_tmu.h   |   22 ++--
>  drivers/thermal/samsung/exynos_tmu_data.c  |  126 
> ++--
>  drivers/thermal/samsung/exynos_tmu_data.h  |   12 +-
>  5 files changed, 249 insertions(+), 38 deletions(-)
>
> --
> 1.7.10.4
Any comments on this patch set please.
>



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4 v9] thermal: samsung: replace inten_ bit fields with intclr_

[Naveen Krishna Ch]

Hello All,

On 12 November 2013 12:06, Naveen Krishna Chatradhi
 wrote:
> This patch replaces the inten_rise_shift/mask and inten_fall_shift/mask
> with intclr_rise_shift/mask and intclr_fall_shift/mask respectively.
> Currently, inten_rise_shift/mask and inten_fall_shift/mask bits are only used
> to configure intclr related registers.
>
> Description of H/W:
> The offset for the bits in the CLEAR register are not consistent across TMU
> modules in Exynso5250, 5420 and 5440.
>
> On Exynos5250, the FALL interrupt related en, status and clear bits are
> available at an offset of
> 16 in INTEN, INTSTAT registers and at an offset of
> 12 in INTCLEAR register.
>
> On Exynos5420, the FALL interrupt related en, status and clear bits are
> available at an offset of
> 16 in INTEN, INTSTAT and INTCLEAR registers.
>
> On Exynos5440,
> the FALL_IRQEN bits are at an offset of 4
> and the RISE_IRQEN bits are at an offset of 0
>
> Signed-off-by: Naveen Krishna Chatradhi 
> ---
> Changes since v8:
> 1. Modified the patch description,
> 2. replaces the inten_rise/fall_shift/mask with intclr_rise/fall_shift/mask
>
>  drivers/thermal/samsung/exynos_tmu.c  |6 +++---
>  drivers/thermal/samsung/exynos_tmu.h  |   16 
>  drivers/thermal/samsung/exynos_tmu_data.c |   18 +-
>  drivers/thermal/samsung/exynos_tmu_data.h |4 ++--
>  4 files changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index 32f38b9..c493245 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -237,7 +237,7 @@ skip_calib_data:
> writeb(pdata->trigger_levels[i], data->base +
> reg->threshold_th0 + i * sizeof(reg->threshold_th0));
>
> -   writel(reg->inten_rise_mask, data->base + reg->tmu_intclear);
> +   writel(reg->intclr_rise_mask, data->base + reg->tmu_intclear);
> } else {
> /* Write temperature code for rising and falling threshold */
> for (i = 0;
> @@ -264,8 +264,8 @@ skip_calib_data:
> writel(falling_threshold,
> data->base + reg->threshold_th1);
>
> -   writel((reg->inten_rise_mask << reg->inten_rise_shift) |
> -   (reg->inten_fall_mask << reg->inten_fall_shift),
> +   writel((reg->intclr_rise_mask << reg->intclr_rise_shift) |
> +   (reg->intclr_fall_mask << reg->intclr_fall_shift),
> data->base + reg->tmu_intclear);
>
> /* if last threshold limit is also present */
> diff --git a/drivers/thermal/samsung/exynos_tmu.h 
> b/drivers/thermal/samsung/exynos_tmu.h
> index 3fb6554..980859a 100644
> --- a/drivers/thermal/samsung/exynos_tmu.h
> +++ b/drivers/thermal/samsung/exynos_tmu.h
> @@ -122,10 +122,6 @@ enum soc_type {
>   * @threshold_th3_l0_shift: shift bits of level0 threshold temperature.
>   * @tmu_inten: register containing the different threshold interrupt
> enable bits.
> - * @inten_rise_shift: shift bits of all rising interrupt bits.
> - * @inten_rise_mask: mask bits of all rising interrupt bits.
> - * @inten_fall_shift: shift bits of all rising interrupt bits.
> - * @inten_fall_mask: mask bits of all rising interrupt bits.
>   * @inten_rise0_shift: shift bits of rising 0 interrupt bits.
>   * @inten_rise1_shift: shift bits of rising 1 interrupt bits.
>   * @inten_rise2_shift: shift bits of rising 2 interrupt bits.
> @@ -136,6 +132,10 @@ enum soc_type {
>   * @inten_fall3_shift: shift bits of falling 3 interrupt bits.
>   * @tmu_intstat: Register containing the interrupt status values.
>   * @tmu_intclear: Register for clearing the raised interrupt status.
> + * @intclr_fall_shift: shift bits for interrupt clear fall 0
> + * @intclr_rise_shift: shift bits of all rising interrupt bits.
> + * @intclr_rise_mask: mask bits of all rising interrupt bits.
> + * @intclr_fall_mask: mask bits of all rising interrupt bits.
>   * @emul_con: TMU emulation controller register.
>   * @emul_temp_shift: shift bits of emulation temperature.
>   * @emul_time_shift: shift bits of emulation time.
> @@ -191,10 +191,6 @@ struct exynos_tmu_registers {
> u32 threshold_th3_l0_shift;
>
> u32 tmu_inten;
> -   u32 inten_rise_shift;
> -   u32 inten_rise_mask;
> -   u32 inten_fall_shift;
> -   u32 inten_fall_mask;
> u32 inten_rise0_shift;
> u32 inten_rise1_shift;
> u32 inten_rise2_shift;
> @@ -207,6 +203,10 @@ struct exynos_tmu_registers {
> u32 tmu_intstat;
>
> u32 tmu_intclear;
> +   u32 intclr_fall_shift;
> +   u32 intclr_rise_shift;
> +   u32 intclr_fall_mask;
> +   u32 intclr_rise_mask;
>
> u32 emul_con;
> u32 emul_temp_shift;
> diff --git a/drivers

Re: [PATCH 2/4 v9] thermal: samsung: change base_common to more meaningful base_second

[Naveen Krishna Ch]

Hello All,

On 12 November 2013 12:06, Naveen Krishna Chatradhi
 wrote:
> On Exynos5440 and Exynos5420 there are registers common
> across the TMU channels.
>
> To support that, we introduced a ADDRESS_MULTIPLE flag in the
> driver and the 2nd set of register base and size are provided
> in the "reg" property of the node.
>
> As per Amit's suggestion, this patch changes the base_common
> to base_second and SHARED_MEMORY to ADDRESS_MULTIPLE.
>
> Signed-off-by: Naveen Krishna Chatradhi 
> ---
> Changes since v8:
>  None
>  .../devicetree/bindings/thermal/exynos-thermal.txt   |4 ++--
>  drivers/thermal/samsung/exynos_tmu.c |   14 
> +++---
>  drivers/thermal/samsung/exynos_tmu.h |4 ++--
>  drivers/thermal/samsung/exynos_tmu_data.c|2 +-
>  4 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> index 284f530..116cca0 100644
> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> @@ -11,8 +11,8 @@
>  - reg : Address range of the thermal registers. For soc's which has multiple
> instances of TMU and some registers are shared across all TMU's like
> interrupt related then 2 set of register has to supplied. First set
> -   belongs to each instance of TMU and second set belongs to common TMU
> -   registers.
> +   belongs to each instance of TMU and second set belongs to second set
> +   of common TMU registers.
>  - interrupts : Should contain interrupt for thermal system
>  - clocks : The main clock for TMU device
>  - clock-names : Thermal system clock name
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index c493245..bbd0fc3 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -41,7 +41,7 @@
>   * @id: identifier of the one instance of the TMU controller.
>   * @pdata: pointer to the tmu platform/configuration data
>   * @base: base address of the single instance of the TMU controller.
> - * @base_common: base address of the common registers of the TMU controller.
> + * @base_second: base address of the common registers of the TMU controller.
>   * @irq: irq number of the TMU controller.
>   * @soc: id of the SOC type.
>   * @irq_work: pointer to the irq work structure.
> @@ -56,7 +56,7 @@ struct exynos_tmu_data {
> int id;
> struct exynos_tmu_platform_data *pdata;
> void __iomem *base;
> -   void __iomem *base_common;
> +   void __iomem *base_second;
> int irq;
> enum soc_type soc;
> struct work_struct irq_work;
> @@ -297,7 +297,7 @@ skip_calib_data:
> }
> /*Clear the PMIN in the common TMU register*/
> if (reg->tmu_pmin && !data->id)
> -   writel(0, data->base_common + reg->tmu_pmin);
> +   writel(0, data->base_second + reg->tmu_pmin);
>  out:
> clk_disable(data->clk);
> mutex_unlock(&data->lock);
> @@ -454,7 +454,7 @@ static void exynos_tmu_work(struct work_struct *work)
>
> /* Find which sensor generated this interrupt */
> if (reg->tmu_irqstatus) {
> -   val_type = readl(data->base_common + reg->tmu_irqstatus);
> +   val_type = readl(data->base_second + reg->tmu_irqstatus);
> if (!((val_type >> data->id) & 0x1))
> goto out;
> }
> @@ -579,7 +579,7 @@ static int exynos_map_dt_data(struct platform_device 
> *pdev)
>  * Check if the TMU shares some registers and then try to map the
>  * memory of common registers.
>  */
> -   if (!TMU_SUPPORTS(pdata, SHARED_MEMORY))
> +   if (!TMU_SUPPORTS(pdata, ADDRESS_MULTIPLE))
> return 0;
>
> if (of_address_to_resource(pdev->dev.of_node, 1, &res)) {
> @@ -587,9 +587,9 @@ static int exynos_map_dt_data(struct platform_device 
> *pdev)
> return -ENODEV;
> }
>
> -   data->base_common = devm_ioremap(&pdev->dev, res.start,
> +   data->base_second = devm_ioremap(&pdev->dev, res.start,
> resource_size(&res));
> -   if (!data->base_common) {
> +   if (!data->base_second) {
> dev_err(&pdev->dev, "Failed to ioremap memory\n");
> return -ENOMEM;
> }
> diff --git a/drivers/thermal/samsung/exynos_tmu.h 
> b/drivers/thermal/samsung/exynos_tmu.h
> index 980859a..0d6b32f 100644
> --- a/drivers/thermal/samsung/exynos_tmu.h
> +++ b/drivers/thermal/samsung/exynos_tmu.h
> @@ -60,7 +60,7 @@ enum soc_type {
>   * state(active/idle) can be checked.
>   * TMU_SUPPORT_EMUL_TIME - This features allows to set next temp emulation
>   * sample time.
> - * TMU

Re: [PATCH 3/4 v9] thermal: samsung: Add TMU support for Exynos5420 SoCs

[Naveen Krishna Ch]

Hello All,

On 12 November 2013 12:07, Naveen Krishna Chatradhi
 wrote:
> Exynos5420 has 5 TMU channels, the TRIMINFO register is
> misplaced for TMU channels 2, 3 and 4
> TRIMINFO at 0x1006c000 contains data for TMU channel 3
> TRIMINFO at 0x100a contains data for TMU channel 4
> TRIMINFO at 0x10068000 contains data for TMU channel 2
>
> This patch
> 1 Adds the neccessary register changes and arch information
>to support Exynos5420 SoCs.
> 2. Handles the gate clock for misplaced TRIMINFO register
> 3. Updates the Documentation at
>Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>
> Signed-off-by: Naveen Krishna Chatradhi 
> Signed-off-by: Andrew Bresticker 
> ---
> Changes since v8:
> 1. rewrote the Documentation for device tree bindings
> 2. Merged the https://lkml.org/lkml/2013/11/7/262 (as this is a fix)
> 3. introduces "samsung,exynos5420-tmu-triminfo" and
>"samsung,exynos5420-tmu-triminfo-clk" to handle the TMU channels on
>Exynos5420 more appropriately
>
>  .../devicetree/bindings/thermal/exynos-thermal.txt |   45 +
>  drivers/thermal/samsung/exynos_tmu.c   |   58 ++-
>  drivers/thermal/samsung/exynos_tmu.h   |2 +
>  drivers/thermal/samsung/exynos_tmu_data.c  |  106 
> 
>  drivers/thermal/samsung/exynos_tmu_data.h  |8 ++
>  5 files changed, 215 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> index 116cca0..5055b31 100644
> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> @@ -6,6 +6,11 @@
>"samsung,exynos4412-tmu"
>"samsung,exynos4210-tmu"
>"samsung,exynos5250-tmu"
> +  "samsung,exynos5420-tmu" for TMU channel 0, 1 on Exynos5420
> +  "samsung,exynos5420-tmu-triminfo" for TMU channel 2 Exynos5420
> +   (Must pass triminfo base)
> +  "samsung,exynos5420-tmu-triminfo-clk" for TMU channel 3 and 4
> +   Exynos5420 (Must pass triminfo base and triminfo 
> clock)
>"samsung,exynos5440-tmu"
>  - interrupt-parent : The phandle for the interrupt controller
>  - reg : Address range of the thermal registers. For soc's which has multiple
> @@ -13,6 +18,18 @@
> interrupt related then 2 set of register has to supplied. First set
> belongs to each instance of TMU and second set belongs to second set
> of common TMU registers.
> +
> +  NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
> +   channels 2, 3 and 4
> +   Use "samsung,exynos5420-tmu-triminfo" in cases, there is a misplaced
> +   register but no need of another clock to access that base.
> +   Use "samsung,exynos5420-tmu-triminfo-clk" in cases where there is a 
> misplaced
> +   register and we need another clock to access that base.
> +
> +   TRIMINFO at 0x1006c000 contains data for TMU channel 3
> +   TRIMINFO at 0x100a contains data for TMU channel 4
> +   TRIMINFO at 0x10068000 contains data for TMU channel 2
> +
>  - interrupts : Should contain interrupt for thermal system
>  - clocks : The main clock for TMU device
>  - clock-names : Thermal system clock name
> @@ -43,6 +60,34 @@ Example 2):
> clock-names = "tmu_apbif";
> };
>
> +Example 3): (In case of Exynos5420 "with misplaced TRIMINFO register")
> +   /* tmu for CPU2 */
> +   tmu@10068000 {
> +   compatible = "samsung,exynos5420-tmu-triminfo";
> +   reg = <0x10068000 0x100>, <0x1006c000 0x4>;
> +   interrupts = <0 184 0>;
> +   clocks = <&clock 318>;
> +   clock-names = "tmu_apbif";
> +   };
> +
> +   /* tmu for CPU3 */
> +   tmu@1006c000 {
> +   compatible = "samsung,exynos5420-tmu-triminfo-clk";
> +   reg = <0x1006c000 0x100>, <0x100a 0x4>;
> +   interrupts = <0 185 0>;
> +   clocks = <&clock 318>;
> +   clock-names = "tmu_apbif", "tmu_triminfo_apbif";
> +   };
> +
> +   /* tmu for GPU */
> +   tmu@100a {
> +   compatible = "samsung,exynos5420-tmu-triminfo-clk";
> +   reg = <0x100a 0x100>, <0x10068000 0x4>;
> +   interrupts = <0 215 0>;
> +   clocks = <&clock 318>;
> +   clock-names = "tmu_apbif", "tmu_triminfo_apbif";
> +   };
> +
>  Note: For multi-instance tmu each instance should have an alias correctly
>  numbered in "aliases" node.
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index bbd0fc3..826647c 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -47,6 +47,7 @@
>   * @irq_work: pointer to the irq work 

Re: [PATCH 4/4 v3] ARM: dts: Exynos5420: Add device nodes for TMU blocks

[Naveen Krishna Ch]

Hello All,

On 12 November 2013 12:07, Naveen Krishna Chatradhi
 wrote:
> Exynos5420 SoC has per core thermal management unit.
> 5 TMU channels 4 for CPUs and 5th for GPU.
>
> This patch adds the device tree nodes to the DT device list.
>
> Nodes carry the misplaced second base address and the second
> clock to access the misplaced base address.
>
> Signed-off-by: Leela Krishna Amudala 
> Signed-off-by: Naveen Krishna Chatradhi 
> Signed-off-by: Andrew Bresticker 
> ---
> Changes since v2:
> 3. uses the new compatible strings introduced along with adding
>support for Exynso5420.
>
> Changes since v1:
> 1. Nodes carry the misplaced second base address and the second
>clock to access the misplaced base address.
> 2. Correct the clock number for the TMU4
>
>  arch/arm/boot/dts/exynos5420.dtsi |   48 
> +
>  1 file changed, 48 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
> b/arch/arm/boot/dts/exynos5420.dtsi
> index 6ffefd1..d736b40 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -369,4 +369,52 @@
> clock-names = "gscl";
> samsung,power-domain = <&gsc_pd>;
> };
> +
> +   /* tmu for CPU0 */
> +   tmu@1006 {
> +   compatible = "samsung,exynos5420-tmu";
> +   reg = <0x1006 0x100>;
> +   interrupts = <0 65 0>;
> +   clocks = <&clock 318>;
> +   clock-names = "tmu_apbif";
> +   };
> +
> +   /* tmu for CPU1 */
> +   tmu@10064000 {
> +   compatible = "samsung,exynos5420-tmu";
> +   reg = <0x10064000 0x100>;
> +   interrupts = <0 183 0>;
> +   clocks = <&clock 318>;
> +   clock-names = "tmu_apbif";
> +   };
> +
> +   /* tmu for CPU2 */
> +   tmu@10068000 {
> +   compatible = "samsung,exynos5420-tmu-triminfo";
> +   /* 2nd reg is for the misplaced TRIMINFO register */
> +   reg = <0x10068000 0x100>, <0x1006c000 0x4>;
> +   interrupts = <0 184 0>;
> +   clocks = <&clock 318>;
> +   clock-names = "tmu_apbif";
> +   };
> +
> +   /* tmu for CPU3 */
> +   tmu@1006c000 {
> +   compatible = "samsung,exynos5420-tmu-triminfo-clk";
> +   /* 2nd reg is for the misplaced TRIMINFO register */
> +   reg = <0x1006c000 0x100>, <0x100a 0x4>;
> +   interrupts = <0 185 0>;
> +   clocks = <&clock 318>, <&clock 319>;
> +   clock-names = "tmu_apbif", "tmu_apbif_triminfo";
> +   };
> +
> +   /* tmu for GPU */
> +   tmu@100a {
> +   compatible = "samsung,exynos5420-tmu-triminfo-clk";
> +   /* 2nd reg is for the misplaced TRIMINFO register */
> +   reg = <0x100a 0x100>, <0x10068000 0x4>;
> +   interrupts = <0 215 0>;
> +   clocks = <&clock 319>, <&clock 318>;
> +   clock-names = "tmu_apbif", "tmu_apbif_triminfo";
> +   };
>  };
> --
> 1.7.10.4
Any comments on this patch
>



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3 v8] thermal: samsung: Add TMU support for Exynos5420 SoCs

[Naveen Krishna Ch]

Hello Tomasz,

On 7 November 2013 20:39, Tomasz Figa  wrote:
> Hi Naveen,
>
> On Thursday 07 of November 2013 11:23:32 Naveen Krishna Chatradhi wrote:
>> This patch adds the neccessary register changes and arch information
>> to support Exynos5420 SoCs
>> Exynos5420 has 5 TMU channels one for each CPU 0, 1, 2 and 3 and GPU
>>
>> Also updated the Documentation at
>> Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>>
>> Note: The platform data structure will be handled properly once the driver
>>  moves to complete device driver solution.
>
> Huh? I'm not sure what do you mean here.
This driver is handling platform data from a predefined structs in driver files.
Platform data is better handled when sent via Device tree nodes.

Will take up the device tree migration once this set is done.
>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> ---
>> Changes since v1:
>> 1. modified the platform data structure in order to pass SHARED flag
>>for channels that need sharing of address space.
>> 2. https://lkml.org/lkml/2013/8/1/38 is merged into this patch.
>>As the changes are minimum and can be added here.
>> Changes since v3:
>>a. Rearraged the code alphabetically, make exynso5420 come before 
>> exynso5440
>>b. Reduce code duplication in passing platform data by introducing a 
>> common macro
>>   Bartlomiej Zolnierkiewicz Thanks for review and suggestions
>> Changes since v4:
>>  None
>> Changes since v5:
>>  None
>> Changes since v6:
>>  - removed the unsued field "inten_fall_shift"
>>  - defined EXYNOS5420_TMU_CLEAR_FALL_INT_SHIFT instead of using 
>> EXYNOS_TMU_FALL_INT_SHIFT
>> Changes since v7:
>>  - changes ins v6 were moved to the patch 1/3 of this patchset.
>>  - defined EXYNOS5420_TMU_CLEAR_FALL_INT_SHIFT instead of using 
>> EXYNOS_TMU_FALL_INT_SHIFT
>>
>>  .../devicetree/bindings/thermal/exynos-thermal.txt |   39 
>>  drivers/thermal/samsung/exynos_tmu.c   |   12 ++-
>>  drivers/thermal/samsung/exynos_tmu.h   |1 +
>>  drivers/thermal/samsung/exynos_tmu_data.c  |   98 
>> 
>>  drivers/thermal/samsung/exynos_tmu_data.h  |8 ++
>>  5 files changed, 157 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
>> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> index 116cca0..c5f9a74 100644
>> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> @@ -6,6 +6,7 @@
>>  "samsung,exynos4412-tmu"
>>  "samsung,exynos4210-tmu"
>>  "samsung,exynos5250-tmu"
>> +"samsung,exynos5420-tmu"
>
> I would add a second compatible value here for TMU units that have
> misplaced TRIMINFO data, e.g. "samsung,exynos5420-tmu-broken-triminfo"
> and explicitly specify that second reg and clock-names entry is required
> for this compatible value.
Sure
>
>>  "samsung,exynos5440-tmu"
>>  - interrupt-parent : The phandle for the interrupt controller
>>  - reg : Address range of the thermal registers. For soc's which has multiple
>> @@ -13,6 +14,16 @@
>>   interrupt related then 2 set of register has to supplied. First set
>>   belongs to each instance of TMU and second set belongs to second set
>>   of common TMU registers.
>
> nit: A blank line here would be nice.
>
>> +  NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
>> + channels 2, 3 and 4
>> +
>> + TRIMINFO at 0x1006c000 contains data for TMU channel 3
>> + TRIMINFO at 0x100a contains data for TMU channel 4
>> + TRIMINFO at 0x10068000 contains data for TMU channel 2
>> +
>> + The misplaced register address is passed through devicetree as the
>> + second base
>> +
>>  - interrupts : Should contain interrupt for thermal system
>>  - clocks : The main clock for TMU device
>>  - clock-names : Thermal system clock name
>> @@ -43,6 +54,34 @@ Example 2):
>>   clock-names = "tmu_apbif";
>>   };
>>
>> +Example 3): (In case of Exynos5420)
>
> Maybe "in case of misplaced TRIMINFO register" would be better?
Sure
>
>> + /* tmu for CPU2 */
>> + tmu@10068000 {
>> + compatible = "samsung,exynos5420-tmu";
>> + reg = <0x10068000 0x100>, <0x1006c000 0x4>;
>> + interrupts = <0 184 0>;
>> + clocks = <&clock 318>;
>> + clock-names = "tmu_apbif";
>> + };
>> +
>
> I believe that just a single example of a node for a TMU with misplaced
> TRIMINFO register will be enough.
right
>
>> + /* tmu for CPU3 */
>> + tmu@1006c000 {
>> + compatible = "samsung,exynos5420-tmu";
>> + reg = <0x1006c000 0x100>, <0x100a 0x4>;
>> + interrupts = <0 185 0>;
>> + clocks = <&clock 318>;
>> + clock-names = "tmu_apbif";
>> + };
>> +
>> + /* tmu for GPU */
>> + tmu@100a {
>> +  

Re: [PATCH] thermal: exynos: handle gate clock for misplaced TRIMINFO register

[Naveen Krishna Ch]

On 7 November 2013 19:48, Tomasz Figa  wrote:
> Hi Naveen,
>
> On Thursday 07 of November 2013 18:12:34 Naveen Krishna Chatradhi wrote:
>> On Exynos5420 the TMU(4) for GPU has a seperate clock enable bit from
>> the other TMU channels(0 ~ 3). Hence, accessing TRIMINFO for base_second
>> should be acompanied by enabling the respective clock.
>>
>> This patch which allow for a "clk_sec" clock to be specified in the
>> device-tree which will be ungated when accessing the TRIMINFO register.
>>
>> Signed-off-by: Andrew Bresticker 
>> Signed-off-by: Naveen Krishna Chatradhi 
>> ---
>>  drivers/thermal/samsung/exynos_tmu.c |   24 +++-
>>  1 file changed, 23 insertions(+), 1 deletion(-)
>
> This patch modifies the device binding, but fails to mention anything
> about the modification in respective documentation. Please do not do that.
Will make a note to update Documentation from now on.

>
> In addition, since the series adding support for Exynos 5420 has not been
> merged yet, I would rather make this patch a part of that series.
Will merge and upload the whole set, first thing tomorrow.
>
> Also please see my comment below.
>
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
>> b/drivers/thermal/samsung/exynos_tmu.c
>> index b54825a..33edd1a 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
> [snip]
>> @@ -641,6 +650,15 @@ static int exynos_tmu_probe(struct platform_device 
>> *pdev)
>>   if (ret)
>>   return ret;
>>
>> + data->clk_sec = devm_clk_get(&pdev->dev, "tmu_apbif_sec");
>> + if (!IS_ERR(data->clk_sec)) {
>
> This code does not check if the clock was specified for TMU channels that
> require it, i.e. the driver will not fail if you don't specify this clock.
I thought of making it mandatory, And TMU on Exynos5440 may not need
second clock for accessing the second base. I Will confirm with the Exynso5440
specs and update accordingly.
>
> Instead, it would be better create a separate compatible value for such
> channels, like "samsung,exynos5420-tmu-broken-triminfo", for which this
> clock would be mandatory and for which, if this clock is not specified,
> the driver would fail.
Right

Sure Tomasz,
Creating a new compatible makes handling this case really simple

Thanks for reviewing.
>
> Best regards,
> Tomasz
>



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: dts: Exynos5420: Add device nodes for HSI2C blocks

[Naveen Krishna Ch]

On 7 November 2013 18:52, Naveen Krishna Chatradhi
 wrote:
> Exynos5420 SoC has 7 High speed I2C channels, This patch adds
> the device tree nodes to the DT device list.
>
> Signed-off-by: Naveen Krishna Chatradhi 
> Signed-off-by: Andrew Bresticker 
> ---
>  arch/arm/boot/dts/exynos5420.dtsi |   98 
> +
>  1 file changed, 98 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
> b/arch/arm/boot/dts/exynos5420.dtsi
> index 6ffefd1..12f612d 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -34,6 +34,13 @@
> i2c1 = &i2c_1;
> i2c2 = &i2c_2;
> i2c3 = &i2c_3;
> +   i2c4 = &hsi2c_4;
> +   i2c5 = &hsi2c_5;
> +   i2c6 = &hsi2c_6;
> +   i2c7 = &hsi2c_7;
> +   i2c8 = &hsi2c_8;
> +   i2c9 = &hsi2c_9;
> +   i2c10 = &hsi2c_10;
> gsc0 = &gsc_0;
> gsc1 = &gsc_1;
> };
> @@ -333,6 +340,97 @@
> status = "disabled";
> };
>
> +   hsi2c_4: hsi2c@12CA {
> +   compatible = "samsung,exynos5-hsi2c";
> +   reg = <0x12CA 0x1000>;
> +   interrupts = <0 60 0>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&i2c4_hs_bus>;
> +   clocks = <&clock 265>;
> +   clock-names = "hsi2c";
> +   status = "disabled";
> +   };
> +
> +   hsi2c_5: hsi2c@12CB {
> +   compatible = "samsung,exynos5-hsi2c";
> +   reg = <0x12CB 0x1000>;
> +   interrupts = <0 61 0>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&i2c5_hs_bus>;
> +   clocks = <&clock 266>;
> +   clock-names = "hsi2c";
> +   status = "disabled";
> +   };
> +
> +   hsi2c_6: hsi2c@12CC {
> +   compatible = "samsung,exynos5-hsi2c";
> +   reg = <0x12CC 0x1000>;
> +   interrupts = <0 62 0>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&i2c6_hs_bus>;
> +   clocks = <&clock 267>;
> +   clock-names = "hsi2c";
> +   status = "disabled";
> +   };
> +
> +   hsi2c_7: hsi2c@12CD {
> +   compatible = "samsung,exynos5-hsi2c";
> +   reg = <0x12CD 0x1000>;
> +   interrupts = <0 63 0>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&i2c7_hs_bus>;
> +   clocks = <&clock 268>;
> +   clock-names = "hsi2c";
> +   status = "disabled";
> +   };
> +
> +   hsi2c_8: hsi2c@12E0 {
> +   compatible = "samsung,exynos5-hsi2c";
> +   reg = <0x12E0 0x1000>;
> +   interrupts = <0 87 0>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&i2c8_hs_bus>;
> +   clocks = <&clock 281>;
> +   clock-names = "hsi2c";
> +   status = "disabled";
> +   };
> +
> +   hsi2c_9: hsi2c@12E1 {
> +   compatible = "samsung,exynos5-hsi2c";
> +   reg = <0x12E1 0x1000>;
> +   interrupts = <0 88 0>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&i2c9_hs_bus>;
> +   clocks = <&clock 282>;
> +   clock-names = "hsi2c";
> +   status = "disabled";
> +   };
> +
> +   hsi2c_10: hsi2c@12E2 {
> +   compatible = "samsung,exynos5-hsi2c";
> +   reg = <0x12E2 0x1000>;
> +   interrupts = <0 203 0>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&i2c10_hs_bus>;
> +   clocks = <&clock 283>;
> +   clock-names = "hsi2c";
> +   status = "disabled";
> +   };
> +
> hdmi@1453 {
> compatible = "samsung,exynos4212-hdmi";
> reg = <0x1453 0x7>;
> --
> 1.7.10.4
>
Just found that Sachin Kamat already tried to post a similar patch.
http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/24581

I was actually waiting for the High speed I2C driver to get merged
before adding the device tree nodes.

The High speed I2C driver was accepted only a couple of days ago.

-- 
Shine bright,
(: Nav :)
--
To unsubscribe fr

Re: [PATCH 1/3 v8] thermal: samsung: add intclr_fall_shift bit in exynos_tmu_register struct

[Naveen Krishna Ch]

Hi Bartlomiej,

On 7 November 2013 16:18, Bartlomiej Zolnierkiewicz
 wrote:
>
> Hi,
>
> On Thursday, November 07, 2013 11:22:42 AM Naveen Krishna Chatradhi wrote:
>> On Exynos5250, the FALL interrupt related en, status and clear bits are
>> available at an offset of
>> 16 in INTEN, INTSTAT registers and at an offset of
>> 12 in INTCLEAR register.
>>
>> On Exynos5420, the FALL interrupt related en, status and clear bits are
>> available at an offset of
>> 16 in INTEN, INTSTAT and INTCLEAR registers.
>>
>> On Exynos5440,
>> the FALL_IRQEN bits are at an offset of 4
>> and the RISE_IRQEN bits are at an offset of 0
>>
>> This patch introduces a new bit field intclr_fall_shift to handle the
>> offset for exyns5250 and exynos5440
>> Also removes the unused macros EXYNOS_TMU_FALL_INT_SHIFT and
>> EXYNOS5440_TMU_FALL_INT_SHIFT, inten_fall_shift field
>
> Thanks for fixing this.  All three patches look good to me now.
>
> Reviewed-by: Bartlomiej Zolnierkiewicz 

Thanks for all the following up.
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3 v6] thermal: samsung: add intclr_fall_shift bit in exynos_tmu_register

[Naveen Krishna Ch]

Hello Bartlomiej,

My reply is very long delayed sorry.

On 17 October 2013 15:33, Bartlomiej Zolnierkiewicz
 wrote:
>
> Hi Naveen,
>
> On Thursday, October 17, 2013 08:41:13 AM Naveen Krishna Chatradhi wrote:
>> On Exynos5250, the FALL interrupt related en, status and clear bits are
>> available at an offset of
>> 16 in INTEN, INTSTAT registers and at an offset of
>> 12 in INTCLEAR register.
>>
>> On Exynos5420, the FALL interrupt related en, status and clear bits are
>> available at an offset of
>> 16 in INTEN, INTSTAT and INTCLEAR registers.
>>
>> On Exynos5440,
>> the FALL_IRQEN bits are at an offset of 4
>> and the RISE_IRQEN bits are at an offset of 0
>>
>> This patch introduces a new bit field intclr_fall_shift to handle the
>> offset for exyns5250 and exynos5440
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> ---
>> Changes since v1:
>> Changes since v2:
>> Changes since v3:
>>   None
>> Changes since v4:
>>  Correct the CLEAR_FALL_INT_SHIFT for Exynos5250/Exynos5440
>> Changes since v5:
>>  Modify the commit message
>
> Thank you but v5 had more issues which are not fixed yet. Please see below.
>
>>  drivers/thermal/samsung/exynos_tmu.c  |2 +-
>>  drivers/thermal/samsung/exynos_tmu.h  |2 ++
>>  drivers/thermal/samsung/exynos_tmu_data.c |2 ++
>>  drivers/thermal/samsung/exynos_tmu_data.h |4 +++-
>>  4 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
>> b/drivers/thermal/samsung/exynos_tmu.c
>> index 32f38b9..b2202fa 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -265,7 +265,7 @@ skip_calib_data:
>>   data->base + reg->threshold_th1);
>>
>>   writel((reg->inten_rise_mask << reg->inten_rise_shift) |
>> - (reg->inten_fall_mask << reg->inten_fall_shift),
>> + (reg->inten_fall_mask << reg->intclr_fall_shift),
>>   data->base + reg->tmu_intclear);
>>
>>   /* if last threshold limit is also present */
>> diff --git a/drivers/thermal/samsung/exynos_tmu.h 
>> b/drivers/thermal/samsung/exynos_tmu.h
>> index 3fb6554..5f4fe6c 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.h
>> +++ b/drivers/thermal/samsung/exynos_tmu.h
>> @@ -136,6 +136,7 @@ enum soc_type {
>>   * @inten_fall3_shift: shift bits of falling 3 interrupt bits.
>>   * @tmu_intstat: Register containing the interrupt status values.
>>   * @tmu_intclear: Register for clearing the raised interrupt status.
>> + * @intclr_fall_shift: shift bits for interrupt clear fall 0
>>   * @emul_con: TMU emulation controller register.
>>   * @emul_temp_shift: shift bits of emulation temperature.
>>   * @emul_time_shift: shift bits of emulation time.
>> @@ -207,6 +208,7 @@ struct exynos_tmu_registers {
>>   u32 tmu_intstat;
>>
>>   u32 tmu_intclear;
>> + u32 intclr_fall_shift;
>>
>>   u32 emul_con;
>>   u32 emul_temp_shift;
>> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
>> b/drivers/thermal/samsung/exynos_tmu_data.c
>> index 073c292..09a8a27 100644
>> --- a/drivers/thermal/samsung/exynos_tmu_data.c
>> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
>> @@ -123,6 +123,7 @@ static const struct exynos_tmu_registers 
>> exynos4412_tmu_registers = {
>>   .inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
>>   .tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
>>   .tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
>> + .intclr_fall_shift = EXYNOS5250_TMU_CLEAR_FALL_INT_SHIFT,
>>   .emul_con = EXYNOS_EMUL_CON,
>>   .emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
>>   .emul_time_shift = EXYNOS_EMUL_TIME_SHIFT,
>> @@ -228,6 +229,7 @@ static const struct exynos_tmu_registers 
>> exynos5440_tmu_registers = {
>>   .inten_fall0_shift = EXYNOS5440_TMU_INTEN_FALL0_SHIFT,
>>   .tmu_intstat = EXYNOS5440_TMU_S0_7_IRQ,
>>   .tmu_intclear = EXYNOS5440_TMU_S0_7_IRQ,
>> + .intclr_fall_shift = EXYNOS5440_TMU_CLEAR_FALL_INT_SHIFT,
>>   .tmu_irqstatus = EXYNOS5440_TMU_IRQ_STATUS,
>>   .emul_con = EXYNOS5440_TMU_S0_7_DEBUG,
>>   .emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
>> diff --git a/drivers/thermal/samsung/exynos_tmu_data.h 
>> b/drivers/thermal/samsung/exynos_tmu_data.h
>> index a1ea19d..9c1e2c8 100644
>> --- a/drivers/thermal/samsung/exynos_tmu_data.h
>> +++ b/drivers/thermal/samsung/exynos_tmu_data.h
>> @@ -69,9 +69,11 @@
>>  #define EXYNOS_TMU_RISE_INT_MASK 0x111
>>  #define EXYNOS_TMU_RISE_INT_SHIFT0
>>  #define EXYNOS_TMU_FALL_INT_MASK 0x111
>> -#define EXYNOS_TMU_FALL_INT_SHIFT12
>> +#define EXYNOS_TMU_FALL_INT_SHIFT16
>>  #define EXYNOS_TMU_CLEAR_RISE_INT0x111
>>  #define EXYNOS_TMU_CLEAR_FALL_INT(0x111 << 12)
>> +#define EXYNOS5250_TMU_CLEAR_FALL_INT_SHIFT  12
>
> The better name would be EXYNOS_TMU_CLEAR_FALL_INT_SHIFT because it is
> also used on EXYNOS4412.
Okey will do that,
>
> Also in patch #3 you should defi

Re: [PATCH v12] i2c: exynos5: add High Speed I2C controller driver

[Naveen Krishna Ch]

On 16 October 2013 11:00, Naveen Krishna Chatradhi
 wrote:
> Adds support for High Speed I2C driver found in Exynos5 and
> later SoCs from Samsung.
>
> Driver only supports Device Tree method.
>
> Signed-off-by: Naveen Krishna Chatradhi 
> Signed-off-by: Taekgyun Ko 
> Reviewed-by: Simon Glass 
> Tested-by: Andrew Bresticker 
> Signed-off-by: Yuvaraj Kumar C D 
> Signed-off-by: Andrew Bresticker 
> ---
> Changes since v10:
> 1. Remove the incomplete runtime_pm code
> 2. Correct the error checks as suggested by Thomas
> 3. Use i2c_add_numbered_adapter() as suggested
> 4. Modified the irq routine to handle the specific interrupts
> 5. Added spinlocks around the irq code
> 6. Remove the "mode" of operation field from device tree node and use the
>clock-frequency to decide the mode.
>
> Changes since v11:
> 1. Use SIMPLE_DEV_PM_OPS instead of definition
> 2. Use i2c_add_adapter and remove i2c->adap.nr = -1;
> 3. Minor cosmotic changes based on review comments from Wolfram Sang
>
>  .../devicetree/bindings/i2c/i2c-exynos5.txt|   44 ++
>  drivers/i2c/busses/Kconfig |7 +
>  drivers/i2c/busses/Makefile|1 +
>  drivers/i2c/busses/i2c-exynos5.c   |  776 
> 
>  4 files changed, 828 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
>  create mode 100644 drivers/i2c/busses/i2c-exynos5.c
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt 
> b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
> new file mode 100644
> index 000..056732c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
> @@ -0,0 +1,44 @@
> +* Samsung's High Speed I2C controller
> +
> +The Samsung's High Speed I2C controller is used to interface with I2C devices
> +at various speeds ranging from 100khz to 3.4Mhz.
> +
> +Required properties:
> +  - compatible: value should be.
> +  -> "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
> +  - reg: physical base address of the controller and length of memory mapped
> +region.
> +  - interrupts: interrupt number to the cpu.
> +  - #address-cells: always 1 (for i2c addresses)
> +  - #size-cells: always 0
> +
> +  - Pinctrl:
> +- pinctrl-0: Pin control group to be used for this controller.
> +- pinctrl-names: Should contain only one value - "default".
> +
> +Optional properties:
> +  - clock-frequency: Desired operating frequency in Hz of the bus.
> +-> If not specified, the bus operates in fast-speed mode at
> +   at 100khz.
> +-> If specified, the bus operates in high-speed mode only if the
> +   clock-frequency is >= 1Mhz.
> +
> +Example:
> +
> +hsi2c@12ca {
> +   compatible = "samsung,exynos5-hsi2c";
> +   reg = <0x12ca 0x100>;
> +   interrupts = <56>;
> +   clock-frequency = <10>;
> +
> +   pinctrl-0 = <&i2c4_bus>;
> +   pinctrl-names = "default";
> +
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   s2mps11_pmic@66 {
> +   compatible = "samsung,s2mps11-pmic";
> +   reg = <0x66>;
> +   };
> +};
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index fcdd321..69b1848 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -436,6 +436,13 @@ config I2C_EG20T
>   ML7213/ML7223/ML7831 is companion chip for Intel Atom E6xx series.
>   ML7213/ML7223/ML7831 is completely compatible for Intel EG20T PCH.
>
> +config I2C_EXYNOS5
> +   tristate "Exynos5 high-speed I2C driver"
> +   depends on ARCH_EXYNOS5 && OF
> +   help
> + Say Y here to include support for high-speed I2C controller in the
> + Exynos5 based Samsung SoCs.
> +
>  config I2C_GPIO
> tristate "GPIO-based bitbanging I2C"
> depends on GPIOLIB
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index d00997f..d1ad371 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -42,6 +42,7 @@ i2c-designware-platform-objs := i2c-designware-platdrv.o
>  obj-$(CONFIG_I2C_DESIGNWARE_PCI)   += i2c-designware-pci.o
>  i2c-designware-pci-objs := i2c-designware-pcidrv.o
>  obj-$(CONFIG_I2C_EG20T)+= i2c-eg20t.o
> +obj-$(CONFIG_I2C_EXYNOS5)  += i2c-exynos5.o
>  obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
>  obj-$(CONFIG_I2C_HIGHLANDER)   += i2c-highlander.o
>  obj-$(CONFIG_I2C_IBM_IIC)  += i2c-ibm_iic.o
> diff --git a/drivers/i2c/busses/i2c-exynos5.c 
> b/drivers/i2c/busses/i2c-exynos5.c
> new file mode 100644
> index 000..0b1e904
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-exynos5.c
> @@ -0,0 +1,776 @@
> +/**
> + * i2c-exynos5.c - Samsung Exynos5 I2C Controller Driver
> + *
> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Pub

Re: [PATCH 1/3 v4] thermal: samsung: correct the fall interrupt en, status bit fields

[Naveen Krishna Ch]

On 14 October 2013 21:31, Bartlomiej Zolnierkiewicz
 wrote:
> On Monday, October 14, 2013 10:18:03 AM Eduardo Valentin wrote:
>> On 11-10-2013 11:57, Bartlomiej Zolnierkiewicz wrote:
>> >
>> > Hi,
>> >
>> > On Friday, October 11, 2013 11:10:38 AM Eduardo Valentin wrote:
>> >> Hi Naveen,
>> >>
>> >> On 09-10-2013 10:03, Bartlomiej Zolnierkiewicz wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> All patches (#1-#3) look good to me, FWIW you can add:
>> >>>
>> >>>   Reviewed-by: Bartlomiej Zolnierkiewicz 
>> >>>
>> >>> Please note that (at least) patch #3 conflicts with Lukasz's EXYNOS4412
>> >>> fixup patchset:
>> >>>
>> >>>   https://lkml.org/lkml/2013/10/9/35
>> >>>
>> >>> It is up to Eduardo to resolve this but it probably would be better to
>> >>> merge EXYNOS4412 fixes first and then add EXYNOS5420 support. This would
>> >>> require you to port patch #3 over Lukasz's patchset though.
>> >>
>> >> My question is if this fix applies also to EXYNOS4412, as it  is not
>> >> mentioned in the patch description and the change affects all supported
>> >
>> > This patch doesn't affect EXYNOS4210 as exynos4210_tmu_registers struct
>>
>> I was, at least for now, worried about 4412, as I mentioned above.
>>
>> > uses the default zero value for inten_fall_mask, inten_fall_shift and
>> > intclr_fall_shift.
>> >
>> >> chip version deliberately. Has this change been validated on all
>> >> supported chip versions?
>> >>
>> >> Amit, I saw you ack, but still, it is not clear how this change behaves
>> >> across supported hardware.
>> >
>> > For EXYNOS4412 and EXYNOS5250 this patch doesn't cause any functionality
>> > changes because while the patch changes inten_fall_shift usage to
>> > intclr_fall_shift one in exynos_tmu_initialize() it defines
>> > EXYNOS_TMU_CLEAR_FALL_INT_SHIFT to 12 (old EXYNOS_TMU_FALL_INT_SHIFT
>> > value).
>> >
>>
>> OK. Then the patch is about a symbol rename, right?
>
> Yes and while doing so it also changes the define and the value used on
> EXYNOS5440. I checked this change against the documentation today (please
> see below).
>
>> > This patch only changes driver behavior for EXYNOS5440 on which the
>> > used shift value changes from 4 to 12.
>>
>> I see.
>
> tmu_intstat and tmu_intclear refer to the same register on EXYNOS5440
> (EXYNOS5440_TMU_S0_7_IRQ defined to 0x230) and the documentation that
> I have says that the value 4 (which matches EXYNOS5440_TMU_FALL_INT_SHIFT
> before the patch) should be used for the shift value. However the patch
> doesn't define EXYNOS5440_TMU_CLEAR_FALL_INT_SHIFT and instead makes
> the code use generic EXYNOS_TMU_CLEAR_FALL_INT_SHIFT (defined to value
> 12) also on EXYNOS5440. This doesn't seem correct.

Right EXYNOS5440  User manual says TMU_S0-7_IRQEN register fields
RISE_IRQEN 3:0
FALL_IRQEN 7:4
Will make changes accordingly.

I've only tested on Exynos5250 and Exynos5420.
Depending on Amit for Exynos5440 as i don't hardware available.
>
> Naveen, this issue needs to be either fixed or explained properly (if
> the documentation is wrong) in the patch description. Please also put some
> information about hardware that you've tested your patch on in the patch
> description.
I've seen that the patches won't apply straight.
and there is a compilation warning introduced. Will fix both of them.
>
>> >
>> > PS I've only noticed it now but after this patch inten_fall_shift becomes
>> > unused and can be removed.
>> >
>>
>>
>> Then we should remove it.
>
> I completely agree.
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
>> > Best regards,
>> > --
>> > Bartlomiej Zolnierkiewicz
>> > Samsung R&D Institute Poland
>> > Samsung Electronics
>> >
>> >>>
>> >>> Best regards,
>> >>> --
>> >>> Bartlomiej Zolnierkiewicz
>> >>> Samsung R&D Institute Poland
>> >>> Samsung Electronics
>> >>>
>> >>> On Wednesday, October 09, 2013 05:38:27 PM Naveen Krishna Chatradhi 
>> >>> wrote:
>>  The FALL interrupt related en, status bits are available at an offset of
>>  16 on INTEN, INTSTAT registers and at an offset of
>>  12 on INTCLEAR register.
>> 
>>  This patch corrects the same for exyns5250 and exynos5440
>> 
>>  Signed-off-by: Naveen Krishna Chatradhi 
>>  ---
>>  Changes since v1:
>>  Changes since v2:
>>  Changes since v3:
>>    None
>> 
>>   drivers/thermal/samsung/exynos_tmu.c  |2 +-
>>   drivers/thermal/samsung/exynos_tmu.h  |2 ++
>>   drivers/thermal/samsung/exynos_tmu_data.c |2 ++
>>   drivers/thermal/samsung/exynos_tmu_data.h |3 ++-
>>   4 files changed, 7 insertions(+), 2 deletions(-)
>> 
>>  diff --git a/drivers/thermal/samsung/exynos_tmu.c 
>>  b/drivers/thermal/samsung/exynos_tmu.c
>>  index b43afda..af69209 100644
>>  --- a/drivers/thermal/samsung/exynos_tmu.c
>>  +++ b/drivers/thermal/samsung/exynos_tmu.c
>>  @@ -265,7 +265,7 @@ skip_calib_data:
>>   data->bas

Re: [PATCH 1/3 v3] exynos: i2c: Fix i2c driver to handle NACKs properly

[Naveen Krishna Ch]

On 15 October 2013 11:36, Heiko Schocher  wrote:
> Hello Naveen,
>
> Am 15.10.2013 07:12, schrieb Naveen Krishna Chatradhi:
>
>> The Exynos5 i2c driver does not handle NACKs properly. This change:
>>
>> - fixes the NACK processing problem (do not continue transaction if
>>address cycle was NACKed)
>>
>> - eliminates a fair amount of duplicate code
>>
>> Signed-off-by: Vadim Bendebury
>> Reviewed-by: Simon Glass
>> Signed-off-by: Naveen Krishna Chatradhi
>> ---
>> Changes since v1:
>> Fixed complilation warning in function i2c_init()
>>
>> Changes since v2:
>> None
>>
>>   drivers/i2c/s3c24x0_i2c.c |  214
>> +++--
>>   1 file changed, 90 insertions(+), 124 deletions(-)
>
>
> Hmm.. I think your patchset is for u-boot, or? But I could not find
> the u-boot ml on cc... instead some linux ml ... if so, please resend
> to the u-boot ml ...
>
> (matches for all three patches from you)
I just checked that u-boot mailing list is missing.
I've done the checks you mentioned in the other mail and reposted with
u-b...@lists.denx.de in --to

Thanks for your review.
>
>
> bye,
> Heiko
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] iio: exynos_adc: use wait_for_completion_timeout instead of interruptible

[Naveen Krishna Ch]

On 11 October 2013 20:00, Lars-Peter Clausen  wrote:
> On 10/11/2013 10:23 AM, Naveen Krishna Chatradhi wrote:
>> This patch does the following
>> 1. use wait_for_completion_timeout instead of
>>wait_for_completion_interruptible_timeout
>> 2. Reset software if a timeout happens.
>> 3. Also reduce the timeout to 100milli secs
>
> It is always good to have a description of why a chance should be done in
> the commit message. It is obvious what the patch does by just looking at the
> changed lines, it is not that obvious though why those lines had to be 
> changed.
>
>>
>> Note: submitted for review at https://patchwork.kernel.org/patch/2279591/
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> Cc: Doug Anderson 
>> Cc: Lars-Peter Clausen 
>> ---
>> Changes since v1:
>> As per discussion at
>> http://marc.info/?l=linux-kernel&m=136517637228869&w=3
>>
>> This patch does the following
>> 1. use wait_for_completion_timeout instead of
>>wait_for_completion_interruptible_timeout
>> 2. Reset software if a timeout happens.
>> 3. Also reduce the timeout to 100milli secs
>>
>> Changes since v2:
>> None.
>> Rebased and reposting.
>>
>> ---
>>  drivers/iio/adc/exynos_adc.c |   66 
>> +++---
>>  1 file changed, 36 insertions(+), 30 deletions(-)
>>
>> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
>> index d25b262..f18ed7e 100644
>> --- a/drivers/iio/adc/exynos_adc.c
>> +++ b/drivers/iio/adc/exynos_adc.c
>> @@ -82,7 +82,7 @@ enum adc_version {
>>  #define ADC_CON_EN_START (1u << 0)
>>  #define ADC_DATX_MASK0xFFF
>>
>> -#define EXYNOS_ADC_TIMEOUT   (msecs_to_jiffies(1000))
>> +#define EXYNOS_ADC_TIMEOUT   (msecs_to_jiffies(100))
>>
>>  struct exynos_adc {
>>   void __iomem*regs;
>> @@ -112,6 +112,30 @@ static inline unsigned int 
>> exynos_adc_get_version(struct platform_device *pdev)
>>   return (unsigned int)match->data;
>>  }
>>
>> +static void exynos_adc_hw_init(struct exynos_adc *info)
>> +{
>> + u32 con1, con2;
>> +
>> + if (info->version == ADC_V2) {
>> + con1 = ADC_V2_CON1_SOFT_RESET;
>> + writel(con1, ADC_V2_CON1(info->regs));
>> +
>> + con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
>> + ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
>> + writel(con2, ADC_V2_CON2(info->regs));
>> +
>> + /* Enable interrupts */
>> + writel(1, ADC_V2_INT_EN(info->regs));
>> + } else {
>> + /* set default prescaler values and Enable prescaler */
>> + con1 =  ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
>> +
>> + /* Enable 12-bit ADC resolution */
>> + con1 |= ADC_V1_CON_RES;
>> + writel(con1, ADC_V1_CON(info->regs));
>> + }
>> +}
>> +
>>  static int exynos_read_raw(struct iio_dev *indio_dev,
>>   struct iio_chan_spec const *chan,
>>   int *val,
>> @@ -121,6 +145,7 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
>>   struct exynos_adc *info = iio_priv(indio_dev);
>>   unsigned long timeout;
>>   u32 con1, con2;
>> + int ret;
>>
>>   if (mask != IIO_CHAN_INFO_RAW)
>>   return -EINVAL;
>> @@ -145,16 +170,21 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
>>   ADC_V1_CON(info->regs));
>>   }
>>
>> - timeout = wait_for_completion_interruptible_timeout
>> + timeout = wait_for_completion_timeout
>>   (&info->completion, EXYNOS_ADC_TIMEOUT);
>
> Nitpick: It would be nice to put the &info->completion on the same line as
> the wait_for_completion...
I received a comment from Grant regarding the same.
I'm away from work this weekend. Will submit the code once i get back,
>
>> + if (timeout == 0) {
>> + dev_warn(&indio_dev->dev, "Conversion timed out reseting\n");
>> + exynos_adc_hw_init(info);
>> + ret = -ETIMEDOUT;
>> + } else {
>> + *val = info->value;
>> + ret = IIO_VAL_INT;
>> + }
>>   *val = info->value;
>
> This line above should probably be removed.
Yes this is unnecessary. Will remove this.
>
>>
>>   mutex_unlock(&indio_dev->mlock);
>>
>> - if (timeout == 0)
>> - return -ETIMEDOUT;
>> -
>> - return IIO_VAL_INT;
>> + return ret;
>>  }
>>
>>  static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
>> @@ -226,30 +256,6 @@ static int exynos_adc_remove_devices(struct device 
>> *dev, void *c)
>>   return 0;
>>  }
>>
>> -static void exynos_adc_hw_init(struct exynos_adc *info)
>> -{
>> - u32 con1, con2;
>> -
>> - if (info->version == ADC_V2) {
>> - con1 = ADC_V2_CON1_SOFT_RESET;
>> - writel(con1, ADC_V2_CON1(info->regs));
>> -
>> - con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
>> - ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
>> - writel

Re: [PATCH] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series

[Naveen Krishna Ch]

On 12 October 2013 11:12, Tomasz Figa  wrote:
> On Saturday 12 of October 2013 04:28:51 Tomasz Figa wrote:
>> [Fixing incorrent mail addresses and dropping the old DT ML.]
>>
>> On Saturday 12 of October 2013 04:22:04 Tomasz Figa wrote:
>> > Hi Naveen,
>> >
>> > On Friday 11 of October 2013 16:56:54 Naveen Krishna Chatradhi wrote:
>> > > The exynos5 i2c clock is based on a fixed 66 MHz peripheral clock, and
>> > > therefore is completely independent of the cpu frequency.
>> > > Thus, registering for a CPU freq notifier is very wasteful.
>> > >
>> > > This patch modifes the code such that, i2c bus registers to
>> > > cpu_freq_transition only for non Exynos SoCs.
>> > >
>> > > This change should save a bunch of cpufreq transitions calls
>> > > which does not apply to exynos SoCs.
>> >
>> > The idea is fine, although...
>> >
>> > > Signed-off-by: Naveen Krishna Chatradhi 
>> > > ---
>> > >  drivers/i2c/busses/i2c-s3c2410.c |4 ++--
>> > >  1 file changed, 2 insertions(+), 2 deletions(-)
>> > >
>> > > diff --git a/drivers/i2c/busses/i2c-s3c2410.c 
>> > > b/drivers/i2c/busses/i2c-s3c2410.c
>> > > index cab1c91..d062fa7 100644
>> > > --- a/drivers/i2c/busses/i2c-s3c2410.c
>> > > +++ b/drivers/i2c/busses/i2c-s3c2410.c
>> > > @@ -123,7 +123,7 @@ struct s3c24xx_i2c {
>> > >   struct s3c2410_platform_i2c *pdata;
>> > >   int gpios[2];
>> > >   struct pinctrl  *pctrl;
>> > > -#ifdef CONFIG_CPU_FREQ
>> > > +#if defined(CONFIG_CPU_FREQ) && !defined(CONFIG_ARCH_EXYNOS)
>> >
>> > ...this is not a good coding practice, especially when already having
>> > multiplatform kernels in sight.
>> >
>> > The best way would be to check on which SoC we are running at runtime,
>> > but since this might need changing a lot of code, then at least I would
>> > change this from !defined(EXYNOS) to defined(S3C24XX), so it is not being
>> > compiled in when S3C24XX support is not enabled and if it's enabled then
>> > the notifier will be registered as a safe fallback that will run correctly
>> > on all platforms.
>
> Actually you can simply check for CONFIG_CPU_FREQ_S3C24XX here.
sure, this makes it more meaningful. will make the modifications and resubmit.
>
> Best regards,
> Tomasz
>



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i2c: exynos5: add High Speed I2C controller driver

[Naveen Krishna Ch]

On 8 September 2013 22:33, Wolfram Sang  wrote:
>
> On Wed, Aug 21, 2013 at 02:54:37PM +0530, Naveen Krishna Ch wrote:
>> Adds support for High Speed I2C driver found in Exynos5 and
>> later SoCs from Samsung.
>>
>> Highspeed mode is a minor change in the i2c protocol.
>> Starts with
>> 1. start condition,
>> 2. 8-bit master ID code (1xxx)
>> 3. followed by a NACK bit
>> Once the above conditions are met, the bus is now operates in highspeed mode.
>> The rest of the I2C protocol applies the same.
>
> The description is correct, but it is not a change in the protocol. This
> is fully specified in the I2C specs.
Understood
>
>> Driver only supports Device Tree method.
>>
>> Changes since v1:
>> 1. Added FIFO functionality
>> 2. Added High speed mode functionality
>> 3. Remove SMBUS_QUICK
>> 4. Remove the debugfs functionality
>> 5. Use devm_* functions where ever possible
>> 6. Driver is free from GPIO configs
>> 7. Use OF data string "clock-frequency" to get the bus operating frequencies
>> 8. Split the clock divisor calculation function
>> 9. Add resets for the failed transacton cases
>> 10. Removed retries as core does retries if -EAGAIN is returned
>> 11. Removed mode from device tree info (use speed to distinguish
>> the mode of operation)
>> 12. Use wait_for_completion_timeout as the interruptible case is not tested 
>> well
>> 13. few other bug fixes and cosmetic changes
>> 14. Removed the untested runtime_pm code
>> 15. Removed the retries as core does that
>> 16. Use adap.nr instead of alias
>> 17. Added spinlocks around the irq code
>> 18. Use i2c_add_numbered_adapter() instead of using aliases
>
> Changes since v1 are irrelevant for the patch description.
Will remove
>
>>
>> Signed-off-by: Taekgyun Ko 
>> Signed-off-by: Naveen Krishna Chatradhi 
>> Reviewed-by: Simon Glass 
>> Tested-by: Andrew Bresticker 
>> Signed-off-by: Yuvaraj Kumar C D 
>> Signed-off-by: Andrew Bresticker 
>>
>> ---
>> Wolfram and Thomas Figa thanks for reviewing the code.
>>
>> Changes since v10:
>> 1. Remove the incomplete runtime_pm code
>> 2. Correct the error checks as suggested by Thomas
>> 3. Use i2c_add_numbered_adapter() as suggested
>> 4. Modified the irq routine to handle the specific interrupts
>> 5. Added spinlocks around the irq code
>> 6. Remove the "mode" of operation field from device tree node and use the
>>clock-frequency to decide the mode.
>>
>>  .../devicetree/bindings/i2c/i2c-exynos5.txt|   44 ++
>>  drivers/i2c/busses/Kconfig |7 +
>>  drivers/i2c/busses/Makefile|1 +
>>  drivers/i2c/busses/i2c-exynos5.c   |  799 
>> 
>>  4 files changed, 851 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
>>  create mode 100644 drivers/i2c/busses/i2c-exynos5.c
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt 
>> b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
>> new file mode 100644
>> index 000..805e018
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
>> @@ -0,0 +1,44 @@
>> +* Samsung's High Speed I2C controller
>> +
>> +The Samsung's High Speed I2C controller is used to interface with I2C 
>> devices
>> +at various speeds ranging from 100khz to 3.4Mhz.
>> +
>> +Required properties:
>> +  - compatible: value should be.
>> +  -> "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
>> +  - reg: physical base address of the controller and length of memory mapped
>> +region.
>> +  - interrupts: interrupt number to the cpu.
>> +  - #address-cells: always 1 (for i2c addresses)
>> +  - #size-cells: always 0
>> +
>> +  - Pinctrl:
>> +- pinctrl-0: Pin control group to be used for this controller.
>> +- pinctrl-names: Should contain only one value - "default".
>> +
>> +Optional properties:
>> +  - clock-frequency: Desired operating frequency in Hz of the bus.
>> +-> If not specified, the default value is 100khz in fast-speed mode and
>> +   1Mhz in high-speed mode.
>
> Description doesn't match the current code.
Will correct
>
>> +-> If specified, The bus operates in high-speed mode only if the
>> +   clock-frequency is >= 1Mhz.
>
> s/The/the/
Will correct
>
> ...
>
>> +/*
>> + * e

Re: [PATCH 3/3] thermal: samsung: Add TMU support for Exynos5420 SoCs

[Naveen Krishna Ch]

Hello Bartlomiej,

On 3 October 2013 18:12, Bartlomiej Zolnierkiewicz
 wrote:
>
> Hi,
>
> I would like to see few minor cleanup changes, please see below:
Sure.
>
> On Thursday, October 03, 2013 05:31:42 PM Naveen Krishna Ch wrote:
>> On 4 September 2013 09:53, Naveen Krishna Chatradhi
>>  wrote:
>> > This patch adds the neccessary register changes and arch information
>> > to support Exynos5420 SoCs
>> > Exynos5420 has 5 TMU channels one for each CPU 0, 1, 2 and 3 and GPU
>> >
>> > Also updated the Documentation at
>> > Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> >
>> > Note: The platform data structure will be handled properly once the driver
>> >  moves to complete device driver solution.
>> >
>> > Signed-off-by: Naveen Krishna Chatradhi 
>> > ---
>> > Changes since v1:
>> > 1. modified the platform data structure in order to pass SHARED flag
>> >for channels that need sharing of address space.
>> > 2. https://lkml.org/lkml/2013/8/1/38 is merged into this patch.
>> >As the changes are minimum and can be added here.
>> >
>> >  .../devicetree/bindings/thermal/exynos-thermal.txt |   39 ++
>> >  drivers/thermal/samsung/exynos_tmu.c   |   14 ++-
>> >  drivers/thermal/samsung/exynos_tmu.h   |1 +
>> >  drivers/thermal/samsung/exynos_tmu_data.c  |  130 
>> > 
>> >  drivers/thermal/samsung/exynos_tmu_data.h  |7 ++
>> >  5 files changed, 189 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
>> > b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> > index 116cca0..d70f2a4 100644
>> > --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> > +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> > @@ -7,12 +7,23 @@
>> >"samsung,exynos4210-tmu"
>> >"samsung,exynos5250-tmu"
>> >"samsung,exynos5440-tmu"
>> > +  "samsung,exynos5420-tmu"
>
> it should come before "samsung,exynos5440-tmu"
Done
>
>> >  - interrupt-parent : The phandle for the interrupt controller
>> >  - reg : Address range of the thermal registers. For soc's which has 
>> > multiple
>> > instances of TMU and some registers are shared across all TMU's 
>> > like
>> > interrupt related then 2 set of register has to supplied. First set
>> > belongs to each instance of TMU and second set belongs to second 
>> > set
>> > of common TMU registers.
>> > +  NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
>> > +   channels 2, 3 and 4
>> > +
>> > +   TRIMINFO at 0x1006c000 contains data for TMU channel 3
>> > +   TRIMINFO at 0x100a contains data for TMU channel 4
>> > +   TRIMINFO at 0x10068000 contains data for TMU channel 2
>> > +
>> > +   The misplaced register address is passed through devicetree as the
>> > +   second base
>> > +
>> >  - interrupts : Should contain interrupt for thermal system
>> >  - clocks : The main clock for TMU device
>> >  - clock-names : Thermal system clock name
>> > @@ -43,6 +54,34 @@ Example 2):
>> > clock-names = "tmu_apbif";
>> > };
>> >
>> > +Example 3): (In case of Exynos5420)
>> > +   /* tmu for CPU2 */
>> > +   tmu@10068000 {
>> > +   compatible = "samsung,exynos5420-tmu";
>> > +   reg = <0x10068000 0x100>, <0x1006c000 0x4>;
>> > +   interrupts = <0 184 0>;
>> > +   clocks = <&clock 318>;
>> > +   clock-names = "tmu_apbif";
>> > +   };
>> > +
>> > +   /* tmu for CPU3 */
>> > +   tmu@1006c000 {
>> > +   compatible = "samsung,exynos5420-tmu";
>> > +   reg = <0x1006c000 0x100>, <0x100a 0x4>;
>> > +   interrupts = <0 185 0>;
>> > +   clocks = <&clock 318>;
>> > +   clock-names = "tmu_apbif";
>> > +   };
>> > +
>> > +   /* tmu for GPU */
>> > +   tmu@100a {
>> > +   

Re: [PATCH 3/3] thermal: samsung: Add TMU support for Exynos5420 SoCs

[Naveen Krishna Ch]

On 4 September 2013 09:53, Naveen Krishna Chatradhi
 wrote:
> This patch adds the neccessary register changes and arch information
> to support Exynos5420 SoCs
> Exynos5420 has 5 TMU channels one for each CPU 0, 1, 2 and 3 and GPU
>
> Also updated the Documentation at
> Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>
> Note: The platform data structure will be handled properly once the driver
>  moves to complete device driver solution.
>
> Signed-off-by: Naveen Krishna Chatradhi 
> ---
> Changes since v1:
> 1. modified the platform data structure in order to pass SHARED flag
>for channels that need sharing of address space.
> 2. https://lkml.org/lkml/2013/8/1/38 is merged into this patch.
>As the changes are minimum and can be added here.
>
>  .../devicetree/bindings/thermal/exynos-thermal.txt |   39 ++
>  drivers/thermal/samsung/exynos_tmu.c   |   14 ++-
>  drivers/thermal/samsung/exynos_tmu.h   |1 +
>  drivers/thermal/samsung/exynos_tmu_data.c  |  130 
> 
>  drivers/thermal/samsung/exynos_tmu_data.h  |7 ++
>  5 files changed, 189 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> index 116cca0..d70f2a4 100644
> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
> @@ -7,12 +7,23 @@
>"samsung,exynos4210-tmu"
>"samsung,exynos5250-tmu"
>"samsung,exynos5440-tmu"
> +  "samsung,exynos5420-tmu"
>  - interrupt-parent : The phandle for the interrupt controller
>  - reg : Address range of the thermal registers. For soc's which has multiple
> instances of TMU and some registers are shared across all TMU's like
> interrupt related then 2 set of register has to supplied. First set
> belongs to each instance of TMU and second set belongs to second set
> of common TMU registers.
> +  NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
> +   channels 2, 3 and 4
> +
> +   TRIMINFO at 0x1006c000 contains data for TMU channel 3
> +   TRIMINFO at 0x100a contains data for TMU channel 4
> +   TRIMINFO at 0x10068000 contains data for TMU channel 2
> +
> +   The misplaced register address is passed through devicetree as the
> +   second base
> +
>  - interrupts : Should contain interrupt for thermal system
>  - clocks : The main clock for TMU device
>  - clock-names : Thermal system clock name
> @@ -43,6 +54,34 @@ Example 2):
> clock-names = "tmu_apbif";
> };
>
> +Example 3): (In case of Exynos5420)
> +   /* tmu for CPU2 */
> +   tmu@10068000 {
> +   compatible = "samsung,exynos5420-tmu";
> +   reg = <0x10068000 0x100>, <0x1006c000 0x4>;
> +   interrupts = <0 184 0>;
> +   clocks = <&clock 318>;
> +   clock-names = "tmu_apbif";
> +   };
> +
> +   /* tmu for CPU3 */
> +   tmu@1006c000 {
> +   compatible = "samsung,exynos5420-tmu";
> +   reg = <0x1006c000 0x100>, <0x100a 0x4>;
> +   interrupts = <0 185 0>;
> +   clocks = <&clock 318>;
> +   clock-names = "tmu_apbif";
> +   };
> +
> +   /* tmu for GPU */
> +   tmu@100a {
> +   compatible = "samsung,exynos5420-tmu";
> +   reg = <0x100a 0x100>, <0x10068000 0x4>;
> +   interrupts = <0 215 0>;
> +   clocks = <&clock 318>;
> +   clock-names = "tmu_apbif";
> +   };
> +
>  Note: For multi-instance tmu each instance should have an alias correctly
>  numbered in "aliases" node.
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index 3a55caf..6d34652 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -186,7 +186,12 @@ static int exynos_tmu_initialize(struct platform_device 
> *pdev)
> EXYNOS5440_EFUSE_SWAP_OFFSET + reg->triminfo_data);
> }
> } else {
> -   trim_info = readl(data->base + reg->triminfo_data);
> +   /* On exynos5420 the triminfo register is in the shared space 
> */
> +   if (data->base_second && (data->soc == SOC_ARCH_EXYNOS5420))
> +   trim_info = readl(data->base_second +
> +   reg->triminfo_data);
> +   else
> +   trim_info = readl(data->base + reg->triminfo_data);
> }
> data->temp_error1 = trim_info & EXYNOS_TMU_TEMP_MASK;
> data->temp_error2 = ((trim_info >> reg->triminfo_85_shift) &
> @@ -499,6 +504,10 @@ static const struct of_device_id exynos_tmu_match[] = {
> .compatible

Re: [PATCH 3/3] thermal: exynos: Handle the misplaced TRIMINFO register

[Naveen Krishna Ch]

On 28 August 2013 14:13, amit daniel kachhap  wrote:
> Hi Naveen,
>
> On Wed, Aug 28, 2013 at 11:49 AM, Naveen Krishna Ch
>  wrote:
>> On 28 August 2013 11:33, amit daniel kachhap  wrote:
>>> Hi Naveen
>>>
>>> On Wed, Aug 28, 2013 at 11:15 AM, Naveen Krishna Chatradhi
>>>  wrote:
>>>> This patch adds code to handle the misplaced TRIMINFO register
>>>> incase of Exynos5420.
>>>>
>>>> On Exynos5420 we have a TRIMINFO register being misplaced for
>>>> TMU channels 2, 3 and 4
>>>>
>>>> TRIMINFO at 0x1006c000 contains data for TMU channel 3
>>>> TRIMINFO at 0x100a contains data for TMU channel 4
>>>> TRIMINFO at 0x10068000 contains data for TMU channel 2
>>>>
>>>> The misplaced register address is passed through devicetree and
>>>> map it seperately during probe.
>>>> Also, adds the documentation under devicetree/bindings/thermal/
>>>>
>>>> Signed-off-by: Naveen Krishna Chatradhi 
>>>> ---
>>>>  .../devicetree/bindings/thermal/exynos-thermal.txt |   21 +
>>>>  drivers/thermal/samsung/exynos_tmu.c   |   32 
>>>> +---
>>>>  2 files changed, 49 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
>>>> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>>>> index 284f530..e818473 100644
>>>> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>>>> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>>>> @@ -7,12 +7,21 @@
>>>>"samsung,exynos4210-tmu"
>>>>"samsung,exynos5250-tmu"
>>>>"samsung,exynos5440-tmu"
>>>> +  "samsung,exynos5420-tmu"
>>>>  - interrupt-parent : The phandle for the interrupt controller
>>>>  - reg : Address range of the thermal registers. For soc's which has 
>>>> multiple
>>>> instances of TMU and some registers are shared across all TMU's 
>>>> like
>>>> interrupt related then 2 set of register has to supplied. First set
>>>> belongs to each instance of TMU and second set belongs to common 
>>>> TMU
>>>> registers.
>>>> +
>>>> + ** NOTE FOR EXYNOS5420 **
>>>> +TRIMINFO register is being misplaced for TMU channels 2, 3 and 4
>>>> +
>>>> +TERMINFO for TMU channel 2 is present in address space of TMU channel 
>>>> 3
>>>> +TERMINFO for TMU channel 3 is present in address space of TMU channel 
>>>> 4
>>>> +TERMINFO for TMU channel 4 is present in address space of TMU channel 
>>>> 2
>>>> +
>>>>  - interrupts : Should contain interrupt for thermal system
>>>>  - clocks : The main clock for TMU device
>>>>  - clock-names : Thermal system clock name
>>>> @@ -43,6 +52,18 @@ Example 2):
>>>> clock-names = "tmu_apbif";
>>>> };
>>>>
>>>> +Example 3): In case of Exynos5420 TMU channel 3
>>>> +
>>>> +   /* tmu for CPU3 */
>>>> +   tmu@1006c000 {
>>>> +   compatible = "samsung,exynos5420-tmu";
>>>> +   /* 2nd reg is for the misplaced TRIMINFO register */
>>>> +   reg = <0x1006c000 0x100>, <0x100a 0x4>;
>>>> +   interrupts = <0 185 0>;
>>>> +   clocks = <&clock 318>;
>>>> +   clock-names = "tmu_apbif";
>>>> +   };
>>>> +
>>>>  Note: For multi-instance tmu each instance should have an alias correctly
>>>>  numbered in "aliases" node.
>>>>
>>>> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
>>>> b/drivers/thermal/samsung/exynos_tmu.c
>>>> index bfdfbd6..f95844e 100644
>>>> --- a/drivers/thermal/samsung/exynos_tmu.c
>>>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>>>> @@ -42,6 +42,7 @@
>>>>   * @pdata: pointer to the tmu platform/configuration data
>>>>   * @base: base address of the single instance of the TMU controller.
>>>>   * @base_common: base address of the common registers of the TMU 
>>>&

Re: [PATCH 3/3] thermal: exynos: Handle the misplaced TRIMINFO register

[Naveen Krishna Ch]

On 28 August 2013 11:33, amit daniel kachhap  wrote:
> Hi Naveen
>
> On Wed, Aug 28, 2013 at 11:15 AM, Naveen Krishna Chatradhi
>  wrote:
>> This patch adds code to handle the misplaced TRIMINFO register
>> incase of Exynos5420.
>>
>> On Exynos5420 we have a TRIMINFO register being misplaced for
>> TMU channels 2, 3 and 4
>>
>> TRIMINFO at 0x1006c000 contains data for TMU channel 3
>> TRIMINFO at 0x100a contains data for TMU channel 4
>> TRIMINFO at 0x10068000 contains data for TMU channel 2
>>
>> The misplaced register address is passed through devicetree and
>> map it seperately during probe.
>> Also, adds the documentation under devicetree/bindings/thermal/
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> ---
>>  .../devicetree/bindings/thermal/exynos-thermal.txt |   21 +
>>  drivers/thermal/samsung/exynos_tmu.c   |   32 
>> +---
>>  2 files changed, 49 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
>> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> index 284f530..e818473 100644
>> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> @@ -7,12 +7,21 @@
>>"samsung,exynos4210-tmu"
>>"samsung,exynos5250-tmu"
>>"samsung,exynos5440-tmu"
>> +  "samsung,exynos5420-tmu"
>>  - interrupt-parent : The phandle for the interrupt controller
>>  - reg : Address range of the thermal registers. For soc's which has multiple
>> instances of TMU and some registers are shared across all TMU's like
>> interrupt related then 2 set of register has to supplied. First set
>> belongs to each instance of TMU and second set belongs to common TMU
>> registers.
>> +
>> + ** NOTE FOR EXYNOS5420 **
>> +TRIMINFO register is being misplaced for TMU channels 2, 3 and 4
>> +
>> +TERMINFO for TMU channel 2 is present in address space of TMU channel 3
>> +TERMINFO for TMU channel 3 is present in address space of TMU channel 4
>> +TERMINFO for TMU channel 4 is present in address space of TMU channel 2
>> +
>>  - interrupts : Should contain interrupt for thermal system
>>  - clocks : The main clock for TMU device
>>  - clock-names : Thermal system clock name
>> @@ -43,6 +52,18 @@ Example 2):
>> clock-names = "tmu_apbif";
>> };
>>
>> +Example 3): In case of Exynos5420 TMU channel 3
>> +
>> +   /* tmu for CPU3 */
>> +   tmu@1006c000 {
>> +   compatible = "samsung,exynos5420-tmu";
>> +   /* 2nd reg is for the misplaced TRIMINFO register */
>> +   reg = <0x1006c000 0x100>, <0x100a 0x4>;
>> +   interrupts = <0 185 0>;
>> +   clocks = <&clock 318>;
>> +   clock-names = "tmu_apbif";
>> +   };
>> +
>>  Note: For multi-instance tmu each instance should have an alias correctly
>>  numbered in "aliases" node.
>>
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
>> b/drivers/thermal/samsung/exynos_tmu.c
>> index bfdfbd6..f95844e 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -42,6 +42,7 @@
>>   * @pdata: pointer to the tmu platform/configuration data
>>   * @base: base address of the single instance of the TMU controller.
>>   * @base_common: base address of the common registers of the TMU controller.
>> + * @triminfo_base: misplaced register base for TRIMINFO on Exynos5420 only
>
> Instead of creating this new field you can re-use base_common for
> accessing the second set of register for misplaced triminfo address.
> Also you can rename this variable as base_second.

The purpose and the meaning of the fields are entirely different.
The triminfo is a hardware bug present only in Exynos5420
and the common registers are available only on Exynos5440 i guess.

IMHO, reusing is not a nice idea.
I'm willing to modify the code if there is a better idea.
>
>>   * @irq: irq number of the TMU controller.
>>   * @soc: id of the SOC type.
>>   * @irq_work: pointer to the irq work structure.
>> @@ -57,6 +58,7 @@ struct exynos_tmu_data {
>> struct exynos_tmu_platform_data *pdata;
>> void __iomem *base;
>> void __iomem *base_common;
>> +   void __iomem *triminfo_base;/* Needed only Exynos5420 */
>> int irq;
>> enum soc_type soc;
>> struct work_struct irq_work;
>> @@ -186,7 +188,12 @@ static int exynos_tmu_initialize(struct platform_device 
>> *pdev)
>> EXYNOS5440_EFUSE_SWAP_OFFSET + reg->triminfo_data);
>> }
>> } else {
>> -   trim_info = readl(data->base + reg->triminfo_data);
>> +   /* On exynos5420 TRIMINFO is misplaced for some channels */
>> +   if (data->triminfo_base)
>> +   trim_info = readl(data->triminfo_base

Re: [PATCH] iio: exynos_adc: fix wrong structure extration in suspend and resume

[Naveen Krishna Ch]

On 23 May 2013 10:55, Naveen Krishna Ch  wrote:
> On 23 May 2013 02:46, Jonathan Cameron  wrote:
>> On 05/20/2013 06:09 PM, Doug Anderson wrote:
>>> Naveen,
>>>
>>> On Sun, May 19, 2013 at 11:34 PM, Naveen Krishna Chatradhi
>>>  wrote:
>>>> The exynos_adc device structure was wrongly extracted from the dev*
>>>> correcting the same.
>>>>
>>>> Using the regular conversion of
>>>> struct device* -> struct platform_device* -> struct exynos_adc* seems 
>>>> wrong.
>>>> Instead we should be doing
>>>> struct device* -> struct iio_dev* -> struct exynos_adc*
>>>>
>>>> Signed-off-by: Naveen Krishna Chatradhi 
>>>> ---
>>>>  drivers/iio/adc/exynos_adc.c | 8 
>>>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> Reviewed-by: Doug Anderson 
>> Applied to the fixes-togreg branch of iio.git
>> I'll hopefully send these on to Greg before the weekend.
> Jonathan,
>
> I would like to know any comments on
>
> https://patchwork.kernel.org/patch/2513361/
>
> Its been pending for a while now.
>
> Thanks,
> Naveen
Ping
Any comments please
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>
>
>
> --
> Shine bright,
> (: Nav :)



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10] i2c: exynos5: add High Speed I2C controller driver

[Naveen Krishna Ch]

On 15 August 2013 18:42, Wolfram Sang  wrote:
> On Mon, Jul 01, 2013 at 12:25:19PM +0200, Tomasz Figa wrote:
>> Hi Naveen,
>>
>> Looks mostly good, but see some comments inline.
>
> Ping?
Hello Wolfram,

I made a patch fixing your comments and from Thomas Figa as well.

Meanwhile, we hit a random crash in exynos5_i2c_irq function.
The "len" variable being is still being near the FIFO_MAX after this condition
 len = HSI2C_FIFO_MAX - fifo_level;
 + if (len > i2c->msg->len)
 + len = i2c->msg->len;

Once, we fix this problem. i planned to rebase and submit.

Is it okey with you?

Thanks,
Naveen
>



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] thermal: exynos_tmu: fix wrong error check for mapped memory

[Naveen Krishna Ch]

On 15 August 2013 12:32, Zhang Rui  wrote:
>
> On 三, 2013-08-07 at 14:01 +0530, Naveen Krishna Chatradhi wrote:
> > The error check is checking for a "base" mapped memory base
> > instead of "base_common". Fixing the same.
> >
> > Signed-off-by: Naveen Krishna Chatradhi 
>
> applied. Thanks!
> BTW, can you rebase the other three exynos patches you submitted?
I mistakenly rebased on the master branch.
Later found the code base is a lot different in the for-next branch.
I've it in my pipe line, Will submit at the soon.

Thanks Rui,

>
> thanks,
> rui
> > ---
> >  drivers/thermal/samsung/exynos_tmu.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> > b/drivers/thermal/samsung/exynos_tmu.c
> > index ec01dfe..a033dbb 100644
> > --- a/drivers/thermal/samsung/exynos_tmu.c
> > +++ b/drivers/thermal/samsung/exynos_tmu.c
> > @@ -592,7 +592,7 @@ static int exynos_map_dt_data(struct platform_device 
> > *pdev)
> >
> >   data->base_common = devm_ioremap(&pdev->dev, res.start,
> >   resource_size(&res));
> > - if (!data->base) {
> > + if (!data->base_common) {
> >   dev_err(&pdev->dev, "Failed to ioremap memory\n");
> >   return -ENOMEM;
> >   }
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/




-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V7 23/30] thermal: exynos: Add thermal configuration data for exynos5440 TMU sensor

[Naveen Krishna Ch]

On 26 June 2013 06:54, Jungseok Lee  wrote:
> On Monday, June 24, 2013 7:51 PM, Amit Daniel Kachhap wrote:
>>This patch adds configuration data for exynos5440 soc. Also register
>>definations for the controller are added.
>>
>>Acked-by: Jonghwa Lee 
>>Acked-by: Kukjin Kim 
>>Signed-off-by: Amit Daniel Kachhap 
>>---
>> drivers/thermal/samsung/exynos_tmu.c  |4 ++
>> drivers/thermal/samsung/exynos_tmu_data.c |   71 
>> +
>> drivers/thermal/samsung/exynos_tmu_data.h |7 +++
>> 3 files changed, 82 insertions(+), 0 deletions(-)
>>
>>diff --git a/drivers/thermal/samsung/exynos_tmu.c 
>>b/drivers/thermal/samsung/exynos_tmu.c
>>index 6bc86f6..651f460 100644
>>--- a/drivers/thermal/samsung/exynos_tmu.c
>>+++ b/drivers/thermal/samsung/exynos_tmu.c
>>@@ -456,6 +456,10 @@ static const struct of_device_id exynos_tmu_match[] = {
>>   .compatible = "samsung,exynos5250-tmu",
>>   .data = (void *)EXYNOS5250_TMU_DRV_DATA,
>>   },
>>+  {
>>+  .compatible = "samsung,exynos5440-tmu",
>>+  .data = (void *)EXYNOS5440_TMU_DRV_DATA,
>>+  },
>>   {},
>> };
>> MODULE_DEVICE_TABLE(of, exynos_tmu_match);
>>diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
>>b/drivers/thermal/samsung/exynos_tmu_data.c
>>index 2612b45..5952915 100644
>>--- a/drivers/thermal/samsung/exynos_tmu_data.c
>>+++ b/drivers/thermal/samsung/exynos_tmu_data.c
>>@@ -175,3 +175,74 @@ struct exynos_tmu_init_data const 
>>exynos5250_default_tmu_data = {
>>   .tmu_count = 1,
>> };
>> #endif
>>+
>>+#if defined(CONFIG_SOC_EXYNOS5440)
>>+static const struct exynos_tmu_registers exynos5440_tmu_registers = {
>>+  .triminfo_data = EXYNOS5440_TMU_S0_7_TRIM,
>>+  .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
>>+  .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
>>+  .tmu_ctrl = EXYNOS5440_TMU_S0_7_CTRL,
>>+  .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
>>+  .buf_vref_sel_mask = EXYNOS_TMU_REF_VOLTAGE_MASK,
>>+  .therm_trip_mode_shift = EXYNOS_TMU_TRIP_MODE_SHIFT,
>>+  .therm_trip_mode_mask = EXYNOS_TMU_TRIP_MODE_MASK,
>>+  .therm_trip_en_shift = EXYNOS_TMU_THERM_TRIP_EN_SHIFT,
>>+  .buf_slope_sel_shift = EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT,
>>+  .buf_slope_sel_mask = EXYNOS_TMU_BUF_SLOPE_SEL_MASK,
>>+  .core_en_shift = EXYNOS_TMU_CORE_EN_SHIFT,
>>+  .tmu_status = EXYNOS5440_TMU_S0_7_STATUS,
>>+  .tmu_cur_temp = EXYNOS5440_TMU_S0_7_TEMP,
>>+  .threshold_th0 = EXYNOS5440_TMU_S0_7_TH0,
>>+  .threshold_th1 = EXYNOS5440_TMU_S0_7_TH1,
>>+  .threshold_th2 = EXYNOS5440_TMU_S0_7_TH2,
>>+  .threshold_th3_l0_shift = EXYNOS5440_TMU_TH_RISE4_SHIFT,
>>+  .tmu_inten = EXYNOS5440_TMU_S0_7_IRQEN,
>>+  .inten_rise_mask = EXYNOS5440_TMU_RISE_INT_MASK,
>>+  .inten_rise_shift = EXYNOS5440_TMU_RISE_INT_SHIFT,
>>+  .inten_fall_mask = EXYNOS5440_TMU_FALL_INT_MASK,
>>+  .inten_fall_shift = EXYNOS5440_TMU_FALL_INT_SHIFT,
>>+  .inten_rise0_shift = EXYNOS5440_TMU_INTEN_RISE0_SHIFT,
>>+  .inten_rise1_shift = EXYNOS5440_TMU_INTEN_RISE1_SHIFT,
>>+  .inten_rise2_shift = EXYNOS5440_TMU_INTEN_RISE2_SHIFT,
>>+  .inten_rise3_shift = EXYNOS5440_TMU_INTEN_RISE3_SHIFT,
>>+  .inten_fall0_shift = EXYNOS5440_TMU_INTEN_FALL0_SHIFT,
>>+  .tmu_intstat = EXYNOS5440_TMU_S0_7_IRQ,
>>+  .tmu_intclear = EXYNOS5440_TMU_S0_7_IRQ,
>>+  .tmu_irqstatus = EXYNOS5440_TMU_IRQ_STATUS,
>>+  .emul_con = EXYNOS5440_TMU_S0_7_DEBUG,
>>+  .emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
>>+  .tmu_pmin = EXYNOS5440_TMU_PMIN,
>>+};
>>+
>>+#define EXYNOS5440_TMU_DATA \
>>+  .trigger_levels[0] = 100, \
>>+  .trigger_levels[4] = 105, \
>>+  .trigger_enable[0] = 1, \
>>+  .trigger_type[0] = SW_TRIP, \
>>+  .trigger_type[4] = HW_TRIP, \
>>+  .max_trigger_level = 5, \
>>+  .gain = 5, \
>>+  .reference_voltage = 16, \
>>+  .noise_cancel_mode = 4, \
>>+  .cal_type = TYPE_ONE_POINT_TRIMMING, \
>>+  .cal_mode = 0, \
>
> .cal_mode = SW_MODE is a clearer expression.
>
>>+  .efuse_value = 0x5b2d, \
>
> .efuse_value should be incremented by one.
>
> Thanks,
> Jungseok Lee
>>+  .min_efuse_value = 16, \
>>+  .max_efuse_value = 76, \
>>+  .first_point_trim = 25, \
>>+  .second_point_trim = 70, \
>>+  .default_temp_offset = 25, \
>>+  .type = SOC_ARCH_EXYNOS5440, \
>>+  .registers = &exynos5440_tmu_registers, \
>>+  .features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_FALLING_TRIP | \
>>+  TMU_SUPPORT_MULTI_INST | TMU_SUPPORT_SHARED_MEMORY),
>>+
>>+struct exynos_tmu_init_data const exynos5440_default_tmu_data = {
>>+  .tmu_data = {
>>+  { EXYNOS5440_TMU_DATA } ,
>>+  { EXYNOS5440_TMU_DATA } ,
>>+  { EXYNOS5440_TMU_DATA } ,
>>+  },
>>+  .tmu_count = 3,
>>+};
>>+#endif
>>diff --git a/drivers/thermal/samsung/exynos_tmu_data.h 
>>b/drivers/thermal/samsung/exynos_tmu_data.h
>>index ad

Re: [PATCH V5 17/30] thermal: exynos: Remove non DT based support

[Naveen Krishna Ch]

On 11 June 2013 18:23, Amit Daniel Kachhap  wrote:
> Recently non DT support from Exynos platform is removed and hence
> removing non DT support from the driver also. This will help in easy
> maintainence.
>
> Signed-off-by: Amit Daniel Kachhap 
Hello Amit,

When you remove the non-DT support why have the #ifdef CONFIG_OF in the driver
instead make the dependency in Kconfig itself.
> ---
>  drivers/thermal/samsung/exynos_tmu.c |   17 +
>  1 files changed, 1 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index acbd295..4356118 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -403,19 +403,6 @@ static const struct of_device_id exynos_tmu_match[] = {
>  MODULE_DEVICE_TABLE(of, exynos_tmu_match);
>  #endif
>
> -static struct platform_device_id exynos_tmu_driver_ids[] = {
> -   {
> -   .name   = "exynos4210-tmu",
> -   .driver_data= (kernel_ulong_t)EXYNOS4210_TMU_DRV_DATA,
> -   },
> -   {
> -   .name   = "exynos5250-tmu",
> -   .driver_data= (kernel_ulong_t)EXYNOS5250_TMU_DRV_DATA,
> -   },
> -   { },
> -};
> -MODULE_DEVICE_TABLE(platform, exynos_tmu_driver_ids);
> -
>  static inline struct  exynos_tmu_platform_data *exynos_get_driver_data(
> struct platform_device *pdev)
>  {
> @@ -428,8 +415,7 @@ static inline struct  exynos_tmu_platform_data 
> *exynos_get_driver_data(
> return (struct exynos_tmu_platform_data *) match->data;
> }
>  #endif
> -   return (struct exynos_tmu_platform_data *)
> -   platform_get_device_id(pdev)->driver_data;
> +   return NULL;
>  }
>
>  static int exynos_tmu_probe(struct platform_device *pdev)
> @@ -586,7 +572,6 @@ static struct platform_driver exynos_tmu_driver = {
> },
> .probe = exynos_tmu_probe,
> .remove = exynos_tmu_remove,
> -   .id_table = exynos_tmu_driver_ids,
>  };
>
>  module_platform_driver(exynos_tmu_driver);
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] thermal: exynos: Handle the misplaced TRIMINFO register

[Naveen Krishna Ch]

On 7 August 2013 12:06, amit daniel kachhap  wrote:
> Hi Naveen,
>
> On Thu, Aug 1, 2013 at 4:06 PM, Naveen Krishna Chatradhi
>  wrote:
>> This patch adds code to handle the misplaced TRIMINFO register
>> incase of Exynos5420.
>>
>> On Exynos5420 we have a TRIMINFO register being misplaced for
>> TMU channels 2, 3 and 4
>>
>> TRIMINFO at 0x1006c000 contains data for TMU channel 3
>> TRIMINFO at 0x100a contains data for TMU channel 4
>> TRIMINFO at 0x10068000 contains data for TMU channel 2
>>
>> The misplaced register address is passed through devicetree and
>> map it seperately during probe.
>> Also, adds the documentation under devicetree/bindings/thermal/
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> Reviewed-by: Doug Anderson 
>> ---
>> Changes since v1:
>> Rebased on 
>> http://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git
> Is it rebased against next branch?

Sorry, i re based it on to master.
>>
>>  .../devicetree/bindings/thermal/exynos-thermal.txt |   48 
>> 
>>  drivers/thermal/exynos_thermal.c   |   26 ++-
> In the new directory structure this file is renamed as
> drivers/thermal/samsung/exynos_tmu.c.
Yea, just checked it. Will re-base and submit.
>
> Thanks,
> Amit Daniel
>>  2 files changed, 72 insertions(+), 2 deletions(-)
>>  create mode 100644 
>> Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
>> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> new file mode 100644
>> index 000..1db279e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> @@ -0,0 +1,48 @@
>> +* Exynos Thermal
>> +
>> +Required properties:
>> +- compatible: should be one of the following.
>> +* "samsung,exynos4210-tmu" - for controllers compatible with exynos4210 
>> tmu.
>> +* "samsung,exynos5250-tmu" - for controllers compatible with exynos5250 
>> tmu.
>> +* "samsung,exynos5420-tmu" - for controllers compatible with exynos5420 
>> tmu.
>> +
>> +- reg: physical base address of the controller and length of
>> +  memory mapped region.
>> +
>> +** NOTE FOR EXYNOS5420 **
>> +TRIMINFO register is being misplaced for TMU channels 2, 3 and 4
>> +
>> +TERMINFO for TMU channel 2 is present in address space of TMU channel 3
>> +TERMINFO for TMU channel 3 is present in address space of TMU channel 4
>> +TERMINFO for TMU channel 4 is present in address space of TMU channel 2
>> +
>> +* In such cases the reg property contains the misplaced register 
>> address and
>> +  range as the second parameter.
>> +
>> +- interrupts : interrupt number to the cpu.
>> +- clocks : Clock number as per common clock framework for the cpu.
>> +- clock-names : clock name to be used in the driver
>> +
>> +Example:
>> +
>> +   /* tmu for CPU0 */
>> +   tmu@1006 {
>> +   compatible = "samsung,exynos5420-tmu";
>> +   reg = <0x1006 0x100>;
>> +   interrupts = <0 65 0>;
>> +   clocks = <&clock 318>;
>> +   clock-names = "tmu_apbif";
>> +   };
>> +
>> +Example: In case of Exynos5420 TMU channel 3
>> +
>> +   /* tmu for CPU3 */
>> +   tmu@1006c000 {
>> +   compatible = "samsung,exynos5420-tmu";
>> +   /* 2nd reg is for the misplaced TRIMINFO register */
>> +   reg = <0x1006c000 0x100>, <0x100a 0x4>;
>> +   interrupts = <0 185 0>;
>> +   clocks = <&clock 318>;
>> +   clock-names = "tmu_apbif";
>> +   };
>> +
>> diff --git a/drivers/thermal/exynos_thermal.c 
>> b/drivers/thermal/exynos_thermal.c
>> index d20ce9e..1ad9005 100644
>> --- a/drivers/thermal/exynos_thermal.c
>> +++ b/drivers/thermal/exynos_thermal.c
>> @@ -38,6 +38,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  /* Exynos generic registers */
>>  #define EXYNOS_TMU_REG_TRIMINFO0x0
>> @@ -120,7 +121,7 @@
>>  struct exynos_tmu_data {
>> struct exynos_tmu_platform_data *pdata;
>> struct resource *mem;
>> -   void __iomem *base;
>> +   void __iomem *base, *triminfo_base;
>> int irq;
>> enum soc_type soc;
>> struct work_struct irq_work;
>> @@ -593,8 +594,14 @@ static int exynos_tmu_initialize(struct platform_device 
>> *pdev)
>> __raw_writel(EXYNOS_TRIMINFO_RELOAD,
>> data->base + EXYNOS_TMU_TRIMINFO_CON);
>> }
>> +
>> /* Save trimming info in order to perform calibration */
>> -   trim_info = readl(data->base + EXYNOS_TMU_REG_TRIMINFO);
>> +   if (data->triminfo_base)
>> +   /* On exynos5420 TRIMINFO is misplaced for some channels */
>> +   trim_info = readl(data->triminfo_base);
>> +   else
>> +   trim_info = readl(data->base + EXYNOS_TMU_REG_TRIMINFO);
>> +
>> data->temp_erro

Re: [PATCH] ARM: dts: exynos5420: add ADC device tree node

[Naveen Krishna Ch]

On 2 August 2013 10:20, sunil joshi  wrote:
> Hi Naveen,
> exynos5250.dtsi also needs this entry.
> Pls consider adding adc node in exynos5250.dtsi as well, and move the
> common content of adc node to exynos5.dtsi.
Sure, sunil will run a boot test and submit the code
>
> Regards
> Sunil
>
>
> On Thu, Aug 1, 2013 at 2:58 PM, Naveen Krishna Chatradhi
>  wrote:
>> From: Jaehoon Kim 
>>
>> Add device tree node for ADC in exynos5420.dtsi
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> Signed-off-by: Doug Anderson 
>> ---
>>  arch/arm/boot/dts/exynos5420.dtsi |   11 +++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
>> b/arch/arm/boot/dts/exynos5420.dtsi
>> index 8c54c4b..074e1bc 100644
>> --- a/arch/arm/boot/dts/exynos5420.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420.dtsi
>> @@ -145,4 +145,15 @@
>> clocks = <&clock 260>, <&clock 131>;
>> clock-names = "uart", "clk_uart_baud0";
>> };
>> +
>> +   adc: adc@12D1 {
>> +   compatible = "samsung,exynos-adc-v2";
>> +   reg = <0x12D1 0x100>, <0x10040720 0x4>;
>> +   interrupts = <0 106 0>;
>> +   #io-channel-cells = <1>;
>> +   io-channel-ranges;
>> +   clocks = <&clock 270>;
>> +   clock-names = "adc";
>> +   status = "disabled";
>> +   };
>>  };
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] thermal: exynos: Handle the misplaced TRIMINFO register

[Naveen Krishna Ch]

On 1 August 2013 14:02, amit daniel kachhap  wrote:
> Hi Naveen,
>
> Can you rebase these patches against
> https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux-soc-thermal.git/log/?h=next.
> All these patches have been queued for 3.12 merge and contains the new
> re-structured TMU driver.
Sure, I will re base and submit.
>
> Thanks,
> Amit Daniel
>
> On Thu, Aug 1, 2013 at 11:32 AM, Naveen Krishna Chatradhi
>  wrote:
>> This patch adds code to handle the misplaced TRIMINFO register
>> incase of Exynos5420.
>>
>> On Exynos5420 we have a TRIMINFO register being misplaced for
>> TMU channels 2, 3 and 4
>>
>> TRIMINFO at 0x1006c000 contains data for TMU channel 3
>> TRIMINFO at 0x100a contains data for TMU channel 4
>> TRIMINFO at 0x10068000 contains data for TMU channel 2
>>
>> The misplaced register address is passed through devicetree and
>> map it seperately during probe.
>> Also, adds the documentation under devicetree/bindings/thermal/
>>
>> Signed-off-by: Naveen Krishna Chatradhi 
>> Reviewed-by: Doug Anderson 
>> ---
>>
>> Rebased on http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>> master branch. I'm not sure which one is the right tree to rebase.
>>
>>  .../devicetree/bindings/thermal/exynos-thermal.txt | 48 
>> ++
>>  drivers/thermal/exynos_thermal.c   | 26 +++-
>>  2 files changed, 72 insertions(+), 2 deletions(-)
>>  create mode 100644 
>> Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
>> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> new file mode 100644
>> index 000..1db279e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> @@ -0,0 +1,48 @@
>> +* Exynos Thermal
>> +
>> +Required properties:
>> +- compatible: should be one of the following.
>> +* "samsung,exynos4210-tmu" - for controllers compatible with exynos4210 
>> tmu.
>> +* "samsung,exynos5250-tmu" - for controllers compatible with exynos5250 
>> tmu.
>> +* "samsung,exynos5420-tmu" - for controllers compatible with exynos5420 
>> tmu.
>> +
>> +- reg: physical base address of the controller and length of
>> +  memory mapped region.
>> +
>> +** NOTE FOR EXYNOS5420 **
>> +TRIMINFO register is being misplaced for TMU channels 2, 3 and 4
>> +
>> +TERMINFO for TMU channel 2 is present in address space of TMU channel 3
>> +TERMINFO for TMU channel 3 is present in address space of TMU channel 4
>> +TERMINFO for TMU channel 4 is present in address space of TMU channel 2
>> +
>> +* In such cases the reg property contains the misplaced register 
>> address and
>> +  range as the second parameter.
>> +
>> +- interrupts : interrupt number to the cpu.
>> +- clocks : Clock number as per common clock framework for the cpu.
>> +- clock-names : clock name to be used in the driver
>> +
>> +Example:
>> +
>> +   /* tmu for CPU0 */
>> +   tmu@1006 {
>> +   compatible = "samsung,exynos5420-tmu";
>> +   reg = <0x1006 0x100>;
>> +   interrupts = <0 65 0>;
>> +   clocks = <&clock 318>;
>> +   clock-names = "tmu_apbif";
>> +   };
>> +
>> +Example: In case of Exynos5420 TMU channel 3
>> +
>> +   /* tmu for CPU3 */
>> +   tmu@1006c000 {
>> +   compatible = "samsung,exynos5420-tmu";
>> +   /* 2nd reg is for the misplaced TRIMINFO register */
>> +   reg = <0x1006c000 0x100>, <0x100a 0x4>;
>> +   interrupts = <0 185 0>;
>> +   clocks = <&clock 318>;
>> +   clock-names = "tmu_apbif";
>> +   };
>> +
>> diff --git a/drivers/thermal/exynos_thermal.c 
>> b/drivers/thermal/exynos_thermal.c
>> index cec3f1f..a229314 100644
>> --- a/drivers/thermal/exynos_thermal.c
>> +++ b/drivers/thermal/exynos_thermal.c
>> @@ -38,6 +38,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>  #include  /* for EXYNOS5_PS_HOLD_CONTROL */
>> @@ -123,7 +124,7 @@ struct exynos_thermal_zone;
>>  struct exynos_tmu_data {
>> struct exynos_tmu_platform_data *pdata;
>> struct resource *mem;
>> -   void __iomem *base;
>> +   void __iomem *base, *triminfo_base;
>> int irq;
>> enum soc_type soc;
>> struct work_struct irq_work;
>> @@ -665,8 +666,14 @@ static int exynos_tmu_initialize(struct platform_device 
>> *pdev)
>> __raw_writel(EXYNOS_TRIMINFO_RELOAD,
>> data->base + EXYNOS_TMU_TRIMINFO_CON);
>> }
>> +
>> /* Save trimming info in order to perform calibration */
>> -   trim_info = readl(data->base + EXYNOS_TMU_REG_TRIMINFO);
>> +   if (data->triminfo_base)
>> +   /* On exynos5420 TRIMINFO is misplaced for some channels */
>> +   trim_info = readl(data->triminfo_base);
>> +   else
>> +  

Re: [PATCH v9] i2c: exynos5: add High Speed I2C controller driver

[Naveen Krishna Ch]

On 17 May 2013 15:40, Naveen Krishna Chatradhi  wrote:
>
> Adds support for High Speed I2C driver found in Exynos5 and
> later SoCs from Samsung.
>
> Driver only supports Device Tree method.
>
> Changes since v1:
> 1. Added FIFO functionality
> 2. Added High speed mode functionality
> 3. Remove SMBUS_QUICK
> 4. Remove the debugfs functionality
> 5. Use devm_* functions where ever possible
> 6. Driver is free from GPIO configs (only supports pinctrl method)
> 7. Use OF data string "clock-frequency" to get the bus operating frequencies
> 8. Split the clock divisor calculation function
> 9. Add resets for the failed transacton cases
> 10. few other bug fixes and cosmetic changes
>
> Signed-off-by: Taekgyun Ko 
> Signed-off-by: Naveen Krishna Chatradhi 
> Reviewed-by: Simon Glass 
> Tested-by: Andrew Bresticker 
> Signed-off-by: Yuvaraj Kumar C D 
> Signed-off-by: Andrew Bresticker 


Hello Wolfram,

This driver was submitted, reviewed several times.
and been improved as we were using it.

I did not see any review comments on this driver.
Can we get this merged or Should we wait for few more reviews ?

Sorry for the earlier HTML version of the mail.

Thanks & Regards,
Naveen Krishna

>
> ---
>
> Changes since v8
> 1. improved the device tree bindings description page for i2c-exynos5
> 2. fixed the return value check for devm_ioremap_resource
>
>  .../devicetree/bindings/i2c/i2c-exynos5.txt|   45 +
>  drivers/i2c/busses/Kconfig |7 +
>  drivers/i2c/busses/Makefile|1 +
>  drivers/i2c/busses/i2c-exynos5.c   |  888 
> 
>  4 files changed, 941 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
>  create mode 100644 drivers/i2c/busses/i2c-exynos5.c
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt 
> b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
> new file mode 100644
> index 000..29c01c0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
> @@ -0,0 +1,45 @@
> +* Samsung's High Speed I2C controller
> +
> +The Samsung's High Speed I2C controller is used to interface with I2C devices
> +at various speeds ranging from 100khz to 3.4Mhz.
> +
> +Required properties:
> +  - compatible: value should be.
> +  -> "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
> +  - reg: physical base address of the controller and length of memory mapped
> +region.
> +  - interrupts: interrupt number to the cpu.
> +  - #address-cells: always 1 (for i2c addresses)
> +  - #size-cells: always 0
> +
> +  - Pinctrl:
> +- pinctrl-0: Pin control group to be used for this controller.
> +- pinctrl-names: Should contain only one value - "default".
> +
> +Optional properties:
> +  - samsung,hs-mode: Mode of operation, High speed or Fast speed mode. If not
> +specified, default value is 0.
> +  - clock-frequency: Desired operating frequency in Hz of the bus.
> +If not specified, the default value in Hz is 10.
> +
> +Example:
> +
> +hsi2c@12ca {
> +   compatible = "samsung,exynos5-hsi2c";
> +   reg = <0x12ca 0x100>;
> +   interrupts = <56>;
> +   clock-frequency = <10>;
> +
> +   /* Pinctrl variant begins here */
> +   pinctrl-0 = <&i2c4_bus>;
> +   pinctrl-names = "default";
> +   /* Pinctrl variant ends here */
> +
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   s2mps11_pmic@66 {
> +   compatible = "samsung,s2mps11-pmic";
> +   reg = <0x66>;
> +   };
> +};
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index adfee98..49a665f 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -434,6 +434,13 @@ config I2C_EG20T
>   ML7213/ML7223/ML7831 is companion chip for Intel Atom E6xx series.
>   ML7213/ML7223/ML7831 is completely compatible for Intel EG20T PCH.
>
> +config I2C_EXYNOS5
> +   tristate "Exynos5 high-speed I2C driver"
> +   depends on ARCH_EXYNOS5 && OF
> +   help
> + Say Y here to include support for high-speed I2C controller in the
> + Exynos5 based Samsung SoCs.
> +
>  config I2C_GPIO
> tristate "GPIO-based bitbanging I2C"
> depends on GENERIC_GPIO
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 8f4fc23..b19366c 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -42,6 +42,7 @@ i2c-designware-platform-objs := i2c-designware-platdrv.o
>  obj-$(CONFIG_I2C_DESIGNWARE_PCI)   += i2c-designware-pci.o
>  i2c-designware-pci-objs := i2c-designware-pcidrv.o
>  obj-$(CONFIG_I2C_EG20T)+= i2c-eg20t.o
> +obj-$(CONFIG_I2C_EXYNOS5)  += i2c-exynos5.o
>  obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
>  obj-$(CONFIG_I2C_HIGHLANDER)   += i2c-highlander.o
>  obj-$(CONFIG_I2C_IBM_IIC)  += i2c-ibm_iic.o
> diff --git a/drivers/i2c/b

Re: [PATCH v9] i2c: exynos5: add High Speed I2C controller driver

[Naveen Krishna Ch]

On 17 May 2013 15:40, Naveen Krishna Chatradhi  wrote:
> Adds support for High Speed I2C driver found in Exynos5 and
> later SoCs from Samsung.
>
> Driver only supports Device Tree method.
>
> Changes since v1:
> 1. Added FIFO functionality
> 2. Added High speed mode functionality
> 3. Remove SMBUS_QUICK
> 4. Remove the debugfs functionality
> 5. Use devm_* functions where ever possible
> 6. Driver is free from GPIO configs (only supports pinctrl method)
> 7. Use OF data string "clock-frequency" to get the bus operating frequencies
> 8. Split the clock divisor calculation function
> 9. Add resets for the failed transacton cases
> 10. few other bug fixes and cosmetic changes
>
> Signed-off-by: Taekgyun Ko 
> Signed-off-by: Naveen Krishna Chatradhi 
> Reviewed-by: Simon Glass 
> Tested-by: Andrew Bresticker 
> Signed-off-by: Yuvaraj Kumar C D 
> Signed-off-by: Andrew Bresticker 
> ---
>
> Changes since v8
> 1. improved the device tree bindings description page for i2c-exynos5
> 2. fixed the return value check for devm_ioremap_resource
>
>  .../devicetree/bindings/i2c/i2c-exynos5.txt|   45 +
>  drivers/i2c/busses/Kconfig |7 +
>  drivers/i2c/busses/Makefile|1 +
>  drivers/i2c/busses/i2c-exynos5.c   |  888 
> 
>  4 files changed, 941 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
>  create mode 100644 drivers/i2c/busses/i2c-exynos5.c
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt 
> b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
> new file mode 100644
> index 000..29c01c0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
> @@ -0,0 +1,45 @@
> +* Samsung's High Speed I2C controller
> +
> +The Samsung's High Speed I2C controller is used to interface with I2C devices
> +at various speeds ranging from 100khz to 3.4Mhz.
> +
> +Required properties:
> +  - compatible: value should be.
> +  -> "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
> +  - reg: physical base address of the controller and length of memory mapped
> +region.
> +  - interrupts: interrupt number to the cpu.
> +  - #address-cells: always 1 (for i2c addresses)
> +  - #size-cells: always 0
> +
> +  - Pinctrl:
> +- pinctrl-0: Pin control group to be used for this controller.
> +- pinctrl-names: Should contain only one value - "default".
> +
> +Optional properties:
> +  - samsung,hs-mode: Mode of operation, High speed or Fast speed mode. If not
> +specified, default value is 0.
> +  - clock-frequency: Desired operating frequency in Hz of the bus.
> +If not specified, the default value in Hz is 10.
> +
> +Example:
> +
> +hsi2c@12ca {
> +   compatible = "samsung,exynos5-hsi2c";
> +   reg = <0x12ca 0x100>;
> +   interrupts = <56>;
> +   clock-frequency = <10>;
> +
> +   /* Pinctrl variant begins here */
> +   pinctrl-0 = <&i2c4_bus>;
> +   pinctrl-names = "default";
> +   /* Pinctrl variant ends here */
> +
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   s2mps11_pmic@66 {
> +   compatible = "samsung,s2mps11-pmic";
> +   reg = <0x66>;
> +   };
> +};
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index adfee98..49a665f 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -434,6 +434,13 @@ config I2C_EG20T
>   ML7213/ML7223/ML7831 is companion chip for Intel Atom E6xx series.
>   ML7213/ML7223/ML7831 is completely compatible for Intel EG20T PCH.
>
> +config I2C_EXYNOS5
> +   tristate "Exynos5 high-speed I2C driver"
> +   depends on ARCH_EXYNOS5 && OF
> +   help
> + Say Y here to include support for high-speed I2C controller in the
> + Exynos5 based Samsung SoCs.
> +
>  config I2C_GPIO
> tristate "GPIO-based bitbanging I2C"
> depends on GENERIC_GPIO
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 8f4fc23..b19366c 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -42,6 +42,7 @@ i2c-designware-platform-objs := i2c-designware-platdrv.o
>  obj-$(CONFIG_I2C_DESIGNWARE_PCI)   += i2c-designware-pci.o
>  i2c-designware-pci-objs := i2c-designware-pcidrv.o
>  obj-$(CONFIG_I2C_EG20T)+= i2c-eg20t.o
> +obj-$(CONFIG_I2C_EXYNOS5)  += i2c-exynos5.o
>  obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
>  obj-$(CONFIG_I2C_HIGHLANDER)   += i2c-highlander.o
>  obj-$(CONFIG_I2C_IBM_IIC)  += i2c-ibm_iic.o
> diff --git a/drivers/i2c/busses/i2c-exynos5.c 
> b/drivers/i2c/busses/i2c-exynos5.c
> new file mode 100644
> index 000..33c481d
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-exynos5.c
> @@ -0,0 +1,888 @@
> +/**
> + * i2c-exynos5.c - Samsung Exynos5 I2C Controller Driver
> + *
> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.

Re: [PATCH] iio: exynos_adc: fix wrong structure extration in suspend and resume

[Naveen Krishna Ch]

On 23 May 2013 02:46, Jonathan Cameron  wrote:
> On 05/20/2013 06:09 PM, Doug Anderson wrote:
>> Naveen,
>>
>> On Sun, May 19, 2013 at 11:34 PM, Naveen Krishna Chatradhi
>>  wrote:
>>> The exynos_adc device structure was wrongly extracted from the dev*
>>> correcting the same.
>>>
>>> Using the regular conversion of
>>> struct device* -> struct platform_device* -> struct exynos_adc* seems wrong.
>>> Instead we should be doing
>>> struct device* -> struct iio_dev* -> struct exynos_adc*
>>>
>>> Signed-off-by: Naveen Krishna Chatradhi 
>>> ---
>>>  drivers/iio/adc/exynos_adc.c | 8 
>>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> Reviewed-by: Doug Anderson 
> Applied to the fixes-togreg branch of iio.git
> I'll hopefully send these on to Greg before the weekend.
Jonathan,

I would like to know any comments on

https://patchwork.kernel.org/patch/2513361/

Its been pending for a while now.

Thanks,
Naveen

>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>



--
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] iio: adc: exynos_adc: use devm_ioremap_resource()

[Naveen Krishna Ch]

On 2 May 2013 14:10, Laurent Navet  wrote:
> Replace calls to deprecated devm_request_and_ioremap by devm_ioremap_resource.
>
> Found with coccicheck and this semantic patch:
>  scripts/coccinelle/api/devm_request_and_ioremap.cocci.
>
> Signed-off-by: Laurent Navet 
Hello Laurent,


But, we already have patch from Sachin
http://patches.linaro.org/15833/
lined up for merge.

Thanks for the post.
Naveen
> ---
>  drivers/iio/adc/exynos_adc.c |   12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
> index 9f3a8ef..22d034a 100644
> --- a/drivers/iio/adc/exynos_adc.c
> +++ b/drivers/iio/adc/exynos_adc.c
> @@ -270,16 +270,16 @@ static int exynos_adc_probe(struct platform_device 
> *pdev)
> info = iio_priv(indio_dev);
>
> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -   info->regs = devm_request_and_ioremap(&pdev->dev, mem);
> -   if (!info->regs) {
> -   ret = -ENOMEM;
> +   info->regs = devm_ioremap_resource(&pdev->dev, mem);
> +   if (IS_ERR(info->regs)) {
> +   ret = PTR_ERR(info->regs);
> goto err_iio;
> }
>
> mem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> -   info->enable_reg = devm_request_and_ioremap(&pdev->dev, mem);
> -   if (!info->enable_reg) {
> -   ret = -ENOMEM;
> +   info->enable_reg = devm_ioremap_resource(&pdev->dev, mem);
> +   if (IS_ERR(info->enable_reg)) {
> +   ret = PTR_ERR(info->enable_reg);
> goto err_iio;
> }
>
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: [PATCH v7] i2c: exynos5: add High Speed I2C controller driver

[Naveen Krishna Ch]

On 2 May 2013 16:57, Wolfram Sang  wrote:
> Hi,
>
>> >> +  - Samsung GPIO variant (deprecated):
>> >> +- gpios: The order of the gpios should be the following: .
>> >> +  The gpio specifier depends on the gpio controller.
>> >
>> > Huh? Why should we support a deprecated method with a new driver?
>> >
>
> This was left unanswered. I am curious.
This was a previous reply i sent out to public,
With my recent testing i can remove this deprecated method and use
pinctrl instead.
will be fixed in next revision.
>
>> >> +Optional properties:
>> >> +  - samsung,hs-mode: Mode of operation, High speed or Fast speed mode. 
>> >> If not
>> >> +specified, default value is 0.
>> >> +  - samsung,hs-clock-freq: Desired operating frequency in Hz of the bus.
>> >> +If not specified, the default value in Hz is 10.
>> >> +  - samsung,fs-clock-freq: Desired operarting frequency in Hz of the bus.
>> >> +If not specified, the default value in Hz is 10.
>> >
>> > NACK! We have a generic binding for defining the bus speed. And
>> > shouldn't hs-mode be set depending on the bus speed?
>
> Please use "clock-frequency" here, like other drivers do.
I've tested this as well.
>
>> >> + /* In auto mode the length of xfer cannot be 0 */
>> >> + if (i2c->msg->len == 0)
>> >> + i2c_auto_conf |= 0x1;
>> >
>> > So you send some byte then? Why not reject the message?
>> This is to support the probing the devices (i2cdetect cases)
>
> No! This is not a proper SMBUS_QUICK if you send a byte! If it doesn't
> work without sending data, then your device does not support it. This is
> not uncommon. Please check the smbus specs if you are unsure.
Ok, i will look into it, thanks for pointing out.
With this fix, the i2cdetect works for me though.
>
>> >> + i2c->regs = of_iomap(np, 0);
>> >
>> > devm_ioremap_resource()
>> This was a comment from Thomas on v1.
>> https://lkml.org/lkml/2012/11/27/264
>>
>> Kindly, suggest me which one is more optimal in this case.
>
> "Optimal" is difficult here, but devm_* has momentum and I prefer
> consistency.
I've seen the rate of adaption for devm_* functions, have changed in
my local work.
>
>> Thanks for your valuable time and comments
>
> You're welcome! Thanks for the submission.
Thanks again.
Naveen
>
>Wolfram
>



--
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Fwd: [PATCH v7] i2c: exynos5: add High Speed I2C controller driver

[Naveen Krishna Ch]

On 16 April 2013 15:59, Wolfram Sang  wrote:
> Hi,
>
> thanks for the submission.
>
> On Thu, Apr 04, 2013 at 09:52:01PM -0700, Naveen Krishna Chatradhi wrote:
>> From: Naveen Krishna Chatradhi 
>>
>> Adds support for High Speed I2C driver found in Exynos5 and
>> later SoCs from Samsung.
>> This driver currently supports Auto mode.
>
> Either explain the limitation of this mode or just leave this sentence.
Sure will add bit more explanation
>
>> Driver only supports Device Tree method.
>> Note: Added debugfs support for registers view, not tested.
>
> Then leave it out, please.
I prefer leave it out for now.
>
>>
>> Signed-off-by: Taekgyun Ko 
>> Signed-off-by: Naveen Krishna Chatradhi 
>> Reviewed-by: Simon Glass 
>> Tested-by: Andrew Bresticker 
>> ---
>> change since v6:
>> 1. clock divisor function hs split to handle the error cases
>> 2. Other irq types are handled
>> 3. FIFO are handled more efficiently in TX and RX
>> 4. More function description added
>> 5. handled the return cases in xfer_msg function
>>
>>  .../devicetree/bindings/i2c/i2c-exynos5.txt|   50 ++
>>  drivers/i2c/busses/Kconfig |7 +
>>  drivers/i2c/busses/Makefile|1 +
>>  drivers/i2c/busses/i2c-exynos5.c   |  934 
>> 
>>  4 files changed, 992 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
>>  create mode 100644 drivers/i2c/busses/i2c-exynos5.c
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt 
>> b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
>> new file mode 100644
>> index 000..0bc9347
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
>> @@ -0,0 +1,50 @@
>> +* Samsung's High Speed I2C controller
>> +
>> +The Samsung's High Speed I2C controller is used to interface with I2C 
>> devices
>> +at various speeds ranging from 100khz to 3.4Mhz.
>> +
>> +Required properties:
>> +  - compatible: value should be.
>> +  (a) "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
>> +  - reg: physical base address of the controller and length of memory mapped
>> +region.
>> +  - interrupts: interrupt number to the cpu.
>> +
>> +  - Samsung GPIO variant (deprecated):
>> +- gpios: The order of the gpios should be the following: .
>> +  The gpio specifier depends on the gpio controller.
>
> Huh? Why should we support a deprecated method with a new driver?
>
>> +  - Pinctrl variant (preferred, if available):
>> +- pinctrl-0: Pin control group to be used for this controller.
>> +- pinctrl-names: Should contain only one value - "default".
>> +
>> +Optional properties:
>> +  - samsung,hs-mode: Mode of operation, High speed or Fast speed mode. If 
>> not
>> +specified, default value is 0.
>> +  - samsung,hs-clock-freq: Desired operating frequency in Hz of the bus.
>> +If not specified, the default value in Hz is 10.
>> +  - samsung,fs-clock-freq: Desired operarting frequency in Hz of the bus.
>> +If not specified, the default value in Hz is 10.
>
> NACK! We have a generic binding for defining the bus speed. And
> shouldn't hs-mode be set depending on the bus speed?
>
>> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
>> index adfee98..9fbfa01 100644
>> --- a/drivers/i2c/busses/Kconfig
>> +++ b/drivers/i2c/busses/Kconfig
>> @@ -434,6 +434,13 @@ config I2C_EG20T
>> ML7213/ML7223/ML7831 is companion chip for Intel Atom E6xx series.
>> ML7213/ML7223/ML7831 is completely compatible for Intel EG20T PCH.
>>
>> +config I2C_EXYNOS5
>> + tristate "Exynos5 high-speed I2C driver"
>> + depends on ARCH_EXYNOS5 && OF
>> + help
>> +   Say Y here to include support for High-speed I2C controller in the
>> +   Exynos5 based Samsung SoCs.
>
> s/High/high/
>
>> +struct exynos5_i2c {
>> + struct i2c_adapter  adap;
>> + unsigned intsuspended:1;
>> +
>> + struct i2c_msg  *msg;
>> + struct completion   msg_complete;
>> + unsigned intmsg_ptr;
>> + unsigned intmsg_len;
>> +
>> + unsigned intirq;
>> +
>> + void __iomem*regs;
>> + struct clk  *clk;
>> + struct device   *dev;
>> + int state;
>> +
>> + /* GPIO lines for SDA/SCL*/
>> + int gpios[2];
>> +
>> + /* Controller operating frequency */
>> + unsigned intclock;
>> + unsigned intclk_cycle;
>> + unsigned intclk_div;
>> +
>> + /* HSI2C Controller can operate in
>> +  * 1. High speed upto 3.4Mbps
>> +  * 2. Fast speed upto 1Mbps
>> +  */
>> + int speed_mode;
>> +};
>
> Only one space as indentation after the type, please.
Will change to 1 space for all of them
>
>> +
>> +static const struct of_device_id exynos5_i2c_match[] = {
>> + { .comp

Re: [PATCH v7] i2c: exynos5: add High Speed I2C controller driver

[Naveen Krishna Ch]

On 5 April 2013 10:22, Naveen Krishna Chatradhi
 wrote:
> From: Naveen Krishna Chatradhi 
>
> Adds support for High Speed I2C driver found in Exynos5 and
> later SoCs from Samsung.
> This driver currently supports Auto mode.
>
> Driver only supports Device Tree method.
> Note: Added debugfs support for registers view, not tested.
>
> Signed-off-by: Taekgyun Ko 
> Signed-off-by: Naveen Krishna Chatradhi 
> Reviewed-by: Simon Glass 
> Tested-by: Andrew Bresticker 
> ---
> change since v6:
> 1. clock divisor function hs split to handle the error cases
> 2. Other irq types are handled
> 3. FIFO are handled more efficiently in TX and RX
> 4. More function description added
> 5. handled the return cases in xfer_msg function
>
>  .../devicetree/bindings/i2c/i2c-exynos5.txt|   50 ++
>  drivers/i2c/busses/Kconfig |7 +
>  drivers/i2c/busses/Makefile|1 +
>  drivers/i2c/busses/i2c-exynos5.c   |  934 
> 
>  4 files changed, 992 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
>  create mode 100644 drivers/i2c/busses/i2c-exynos5.c
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt 
> b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
> new file mode 100644
> index 000..0bc9347
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
> @@ -0,0 +1,50 @@
> +* Samsung's High Speed I2C controller
> +
> +The Samsung's High Speed I2C controller is used to interface with I2C devices
> +at various speeds ranging from 100khz to 3.4Mhz.
> +
> +Required properties:
> +  - compatible: value should be.
> +  (a) "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
> +  - reg: physical base address of the controller and length of memory mapped
> +region.
> +  - interrupts: interrupt number to the cpu.
> +
> +  - Samsung GPIO variant (deprecated):
> +- gpios: The order of the gpios should be the following: .
> +  The gpio specifier depends on the gpio controller.
> +  - Pinctrl variant (preferred, if available):
> +- pinctrl-0: Pin control group to be used for this controller.
> +- pinctrl-names: Should contain only one value - "default".
> +
> +Optional properties:
> +  - samsung,hs-mode: Mode of operation, High speed or Fast speed mode. If not
> +specified, default value is 0.
> +  - samsung,hs-clock-freq: Desired operating frequency in Hz of the bus.
> +If not specified, the default value in Hz is 10.
> +  - samsung,fs-clock-freq: Desired operarting frequency in Hz of the bus.
> +If not specified, the default value in Hz is 10.
> +
> +Example:
> +
> +   hsi2c@12ca {
> +   compatible = "samsung,exynos5-hsi2c";
> +   reg = <0x12ca 0x100>;
> +   interrupts = <56>;
> +   samsung,fs-clock-freq = <10>;
> +   /* Samsung GPIO variant begins here */
> +   gpios = <&gpd1 2 0 /* SDA */
> +&gpd1 3 0 /* SCL */>;
> +   /* Samsung GPIO variant ends here */
> +   /* Pinctrl variant begins here */
> +   pinctrl-0 = <&i2c4_bus>;
> +   pinctrl-names = "default";
> +   /* Pinctrl variant ends here */
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   s2mps11_pmic@66 {
> +   compatible = "samsung,s2mps11-pmic";
> +   reg = <0x66>;
> +   };
> +   };
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index adfee98..9fbfa01 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -434,6 +434,13 @@ config I2C_EG20T
>   ML7213/ML7223/ML7831 is companion chip for Intel Atom E6xx series.
>   ML7213/ML7223/ML7831 is completely compatible for Intel EG20T PCH.
>
> +config I2C_EXYNOS5
> +   tristate "Exynos5 high-speed I2C driver"
> +   depends on ARCH_EXYNOS5 && OF
> +   help
> + Say Y here to include support for High-speed I2C controller in the
> + Exynos5 based Samsung SoCs.
> +
>  config I2C_GPIO
> tristate "GPIO-based bitbanging I2C"
> depends on GENERIC_GPIO
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 8f4fc23..b19366c 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -42,6 +42,7 @@ i2c-designware-platform-objs := i2c-designware-platdrv.o
>  obj-$(CONFIG_I2C_DESIGNWARE_PCI)   += i2c-designware-pci.o
>  i2c-designware-pci-objs := i2c-designware-pcidrv.o
>  obj-$(CONFIG_I2C_EG20T)+= i2c-eg20t.o
> +obj-$(CONFIG_I2C_EXYNOS5)  += i2c-exynos5.o
>  obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
>  obj-$(CONFIG_I2C_HIGHLANDER)   += i2c-highlander.o
>  obj-$(CONFIG_I2C_IBM_IIC)  += i2c-ibm_iic.o
> diff --git a/drivers/i2c/busses/i2c-exynos5.c 
> b/drivers/i

Re: [PATCH v2 2/4] iio: adc: Add dt support for turning on the phy in exynos-adc

[Naveen Krishna Ch]

On 13 March 2013 13:40, Doug Anderson  wrote:
> Without this change the exynos adc controller needed to have its phy
> enabled in some out-of-driver C code.  Add support for specifying the
> phy enable register by listing it in the reg list.
>
> Signed-off-by: Doug Anderson 
> ---
> Changes in v2: None
Reviewed-by: Naveen Krishna Chatradhi 

Lars, any update on this patch set. This change is required.
>
>  .../devicetree/bindings/arm/samsung/exynos-adc.txt |  4 ++--
>  drivers/iio/adc/exynos_adc.c   | 14 
> +-
>  2 files changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt 
> b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> index 96db940..05be151 100644
> --- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> @@ -15,7 +15,7 @@ Required properties:
> Must be "samsung,exynos-adc-v2" for
> future controllers.
>  - reg: Contains ADC register address range (base address and
> -   length).
> +   length) and the address of the phy enable register.
>  - interrupts:  Contains the interrupt information for the timer. The
> format is being dependent on which interrupt 
> controller
> the Samsung device uses.
> @@ -30,7 +30,7 @@ Example: adding device info in dtsi file
>
>  adc: adc@12D1 {
> compatible = "samsung,exynos-adc-v1";
> -   reg = <0x12D1 0x100>;
> +   reg = <0x12D1 0x100>, <0x10040718 0x4>;
> interrupts = <0 106 0>;
> #io-channel-cells = <1>;
> io-channel-ranges;
> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
> index ed6fdd7..5ab0dfd 100644
> --- a/drivers/iio/adc/exynos_adc.c
> +++ b/drivers/iio/adc/exynos_adc.c
> @@ -85,6 +85,7 @@ enum adc_version {
>
>  struct exynos_adc {
> void __iomem*regs;
> +   void __iomem*enable_reg;
> struct clk  *clk;
> unsigned intirq;
> struct regulator*vdd;
> @@ -269,13 +270,19 @@ static int exynos_adc_probe(struct platform_device 
> *pdev)
> info = iio_priv(indio_dev);
>
> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -
> info->regs = devm_request_and_ioremap(&pdev->dev, mem);
> if (!info->regs) {
> ret = -ENOMEM;
> goto err_iio;
> }
>
> +   mem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> +   info->enable_reg = devm_request_and_ioremap(&pdev->dev, mem);
> +   if (!info->enable_reg) {
> +   ret = -ENOMEM;
> +   goto err_iio;
> +   }
> +
> irq = platform_get_irq(pdev, 0);
> if (irq < 0) {
> dev_err(&pdev->dev, "no irq resource?\n");
> @@ -295,6 +302,8 @@ static int exynos_adc_probe(struct platform_device *pdev)
> goto err_iio;
> }
>
> +   writel(1, info->enable_reg);
> +
> info->clk = devm_clk_get(&pdev->dev, "adc");
> if (IS_ERR(info->clk)) {
> dev_err(&pdev->dev, "failed getting clock, err = %ld\n",
> @@ -370,6 +379,7 @@ static int exynos_adc_remove(struct platform_device *pdev)
> exynos_adc_remove_devices);
> regulator_disable(info->vdd);
> clk_disable_unprepare(info->clk);
> +   writel(0, info->enable_reg);
> iio_device_unregister(indio_dev);
> free_irq(info->irq, info);
> iio_device_free(indio_dev);
> @@ -395,6 +405,7 @@ static int exynos_adc_suspend(struct device *dev)
> }
>
> clk_disable_unprepare(info->clk);
> +   writel(0, info->enable_reg);
> regulator_disable(info->vdd);
>
> return 0;
> @@ -410,6 +421,7 @@ static int exynos_adc_resume(struct device *dev)
> if (ret)
> return ret;
>
> +   writel(1, info->enable_reg);
> clk_prepare_enable(info->clk);
>
> exynos_adc_hw_init(info);
> --
> 1.8.1.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



--
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 4/4] ARM: dts: Add adc and thermistors for exynos5250-snow

[Naveen Krishna Ch]

On 15 March 2013 08:42, Naveen Krishna Ch  wrote:
> On 15 March 2013 15:54, Naveen Krishna Ch  wrote:
>> Doug,
>>
>> On 14 March 2013 02:10, Doug Anderson  wrote:
>>> Hook up the exynos5250-snow thermistors via the device tree now that
>>> there's a driver available to use them.
>>>
>>> Signed-off-by: Doug Anderson 
> Tested-by: Naveen Krishna Chatradhi 
> used these changes to test on snow before submitting the ADC and NTC
> driver changes.
Kukjin, Any update on this patch. you want us to rebase it ?

>>> ---
>>> Changes in v2:
>>> - Match 'uV' -> 'uv' change in Naveen's bindings.
>>>
>>>  arch/arm/boot/dts/cros5250-common.dtsi |  4 
>>>  arch/arm/boot/dts/exynos5250-snow.dts  | 31 +++
>>>  2 files changed, 35 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/cros5250-common.dtsi 
>>> b/arch/arm/boot/dts/cros5250-common.dtsi
>>> index 46c0980..f7cc835 100644
>>> --- a/arch/arm/boot/dts/cros5250-common.dtsi
>>> +++ b/arch/arm/boot/dts/cros5250-common.dtsi
>>> @@ -167,6 +167,10 @@
>>> status = "disabled";
>>> };
>>>
>>> +   adc@12D1 {
>>> +   vdd-supply = <&buck5_reg>;
>>> +   };
>>> +
>>> hdmi {
>>> hpd-gpio = <&gpx3 7 0xf 1 3>;
>>> };
>>> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
>>> b/arch/arm/boot/dts/exynos5250-snow.dts
>>> index 17dd951..b78da7c 100644
>>> --- a/arch/arm/boot/dts/exynos5250-snow.dts
>>> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
>>> @@ -40,4 +40,35 @@
>>> <&gpc4 5 2 3 0>, <&gpc4 6 2 3 0>;
>>> };
>>> };
>>> +
>>> +   adc@12D1 {
>>> +   ncp15wb473@3 {
>>> +   compatible = "ntc,ncp15wb473";
>>> +   pullup-uv = <180>;
>>> +   pullup-ohm = <47000>;
>>> +   pulldown-ohm = <0>;
>>> +   io-channels = <&adc 3>;
>>> +   };
>>> +   ncp15wb473@4 {
>>> +   compatible = "ntc,ncp15wb473";
>>> +   pullup-uv = <180>;
>>> +   pullup-ohm = <47000>;
>>> +   pulldown-ohm = <0>;
>>> +   io-channels = <&adc 4>;
>>> +   };
>>> +   ncp15wb473@5 {
>>> +   compatible = "ntc,ncp15wb473";
>>> +   pullup-uv = <180>;
>>> +   pullup-ohm = <47000>;
>>> +   pulldown-ohm = <0>;
>>> +   io-channels = <&adc 5>;
>>> +   };
>>> +   ncp15wb473@6 {
>>> +   compatible = "ntc,ncp15wb473";
>>> +   pullup-uv = <180>;
>>> +   pullup-ohm = <47000>;
>>> +   pulldown-ohm = <0>;
>>> +   io-channels = <&adc 6>;
>>> +   };
>>> +   };
>>>  };
>> Thanks for the upload, i've tested with a similar changes.
>>> --
>>> 1.8.1.3
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>>
>>
>> --
>> Shine bright,
>> (: Nav :)
>
>
>
> --
> Shine bright,
> (: Nav :)



--
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/4] iio: adc: Document the regulator/clocks for exynos-adc

[Naveen Krishna Ch]

On 13 March 2013 13:39, Doug Anderson  wrote:
> The exynos ADC won't work without a regulator called "vdd" and a clock
> called "adc".  Document this fact in the device tree bindings.
>
> Signed-off-by: Doug Anderson 
Reviewed-by: Naveen Krishna Chatradhi 

Lars, any update on this patch set. This change is required.
> ---
> Changes in v2: None
>
>  Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt 
> b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> index f686378..96db940 100644
> --- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
> @@ -20,6 +20,9 @@ Required properties:
> format is being dependent on which interrupt 
> controller
> the Samsung device uses.
>  - #io-channel-cells = <1>; As ADC has multiple outputs
> +- clocks   From common clock binding: handle to adc clock.
> +- clock-names  From common clock binding: Shall be "adc".
> +- vdd-supply   VDD input supply.
>
>  Note: child nodes can be added for auto probing from device tree.
>
> @@ -31,6 +34,11 @@ adc: adc@12D1 {
> interrupts = <0 106 0>;
> #io-channel-cells = <1>;
> io-channel-ranges;
> +
> +   clocks = <&clock 303>;
> +   clock-names = "adc";
> +
> +   vdd-supply = <&buck5_reg>;
>  };
>
>
> --
> 1.8.1.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



--
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i2c: exynos5: add High Speed I2C controller driver

[Naveen Krishna Ch]

On 12 March 2013 18:43, Simon Glass  wrote:
> [please excuse my mailer html confusion]
>
> Hi Naveen,
>
> On Mon, Mar 11, 2013 at 9:32 PM, Naveen Krishna Chatradhi
>  wrote:
>>
>> Adds support for High Speed I2C driver found in Exynos5 and later
>> SoCs from Samsung. This driver currently supports Auto mode.
>>
>> Driver only supports Device Tree method.
>> Note: Added debugfs support for registers view, not tested.
>>
>> Signed-off-by: Taekgyun Ko 
>> Signed-off-by: Naveen Krishna Chatradhi 
>> Cc: R. Chandrasekar 
>> ---
>> Changes since v3: http://lkml.org/lkml/2012/12/28/46
>> 1. Added Documentation for DT bindings
>> 2. Removed the bus_num, as Doug's pick id from DT is merged in i2c/for-next
>> 3. Split the xfer function for better clarity.
>> 4. Streamlined code flow in isr, handled trans_status register in xfer_msg 
>> call.
>>
>>  .../devicetree/bindings/i2c/i2c-exynos5.txt|   50 ++
>>  drivers/i2c/busses/Kconfig |7 +
>>  drivers/i2c/busses/Makefile|1 +
>>  drivers/i2c/busses/i2c-exynos5.c   |  743 
>> 
>>  4 files changed, 801 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
>>  create mode 100644 drivers/i2c/busses/i2c-exynos5.c
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt 
>> b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
>> new file mode 100644
>> index 000..0bc9347
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
>> @@ -0,0 +1,50 @@
>> +* Samsung's High Speed I2C controller
>> +
>> +The Samsung's High Speed I2C controller is used to interface with I2C 
>> devices
>> +at various speeds ranging from 100khz to 3.4Mhz.
>> +
>> +Required properties:
>> +  - compatible: value should be.
>> +  (a) "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
>> +  - reg: physical base address of the controller and length of memory mapped
>> +region.
>> +  - interrupts: interrupt number to the cpu.
>> +
>> +  - Samsung GPIO variant (deprecated):
>> +- gpios: The order of the gpios should be the following: .
>> +  The gpio specifier depends on the gpio controller.
>> +  - Pinctrl variant (preferred, if available):
>> +- pinctrl-0: Pin control group to be used for this controller.
>> +- pinctrl-names: Should contain only one value - "default".
>> +
>> +Optional properties:
>> +  - samsung,hs-mode: Mode of operation, High speed or Fast speed mode. If 
>> not
>> +specified, default value is 0.
>> +  - samsung,hs-clock-freq: Desired operating frequency in Hz of the bus.
>> +If not specified, the default value in Hz is 10.
>> +  - samsung,fs-clock-freq: Desired operarting frequency in Hz of the bus.
>> +If not specified, the default value in Hz is 10.
>> +
>> +Example:
>> +
>> +   hsi2c@12ca {
>> +   compatible = "samsung,exynos5-hsi2c";
>> +   reg = <0x12ca 0x100>;
>> +   interrupts = <56>;
>> +   samsung,fs-clock-freq = <10>;
>> +   /* Samsung GPIO variant begins here */
>> +   gpios = <&gpd1 2 0 /* SDA */
>> +&gpd1 3 0 /* SCL */>;
>> +   /* Samsung GPIO variant ends here */
>> +   /* Pinctrl variant begins here */
>> +   pinctrl-0 = <&i2c4_bus>;
>> +   pinctrl-names = "default";
>> +   /* Pinctrl variant ends here */
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +
>> +   s2mps11_pmic@66 {
>> +   compatible = "samsung,s2mps11-pmic";
>> +   reg = <0x66>;
>> +   };
>> +   };
>> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
>> index a3725de..78b4936 100644
>> --- a/drivers/i2c/busses/Kconfig
>> +++ b/drivers/i2c/busses/Kconfig
>> @@ -434,6 +434,13 @@ config I2C_EG20T
>>   ML7213/ML7223/ML7831 is companion chip for Intel Atom E6xx series.
>>   ML7213/ML7223/ML7831 is completely compatible for Intel EG20T PCH.
>>
>> +config I2C_EXYNOS5
>> +   tristate "Exynos5 high-speed I2C driver"
>> +   depends on ARCH_EXYNOS5 && OF
>> +   help
>> + Say Y here to include support for High-speed I2C controller in the
>> + Exynos5 based Samsung SoCs.
>> +
>>  config I2C_GPIO
>> tristate "GPIO-based bitbanging I2C"
>> depends on GENERIC_GPIO
>> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
>> index 8f4fc23..b19366c 100644
>> --- a/drivers/i2c/busses/Makefile
>> +++ b/drivers/i2c/busses/Makefile
>> @@ -42,6 +42,7 @@ i2c-designware-platform-objs := i2c-designware-platdrv.o
>>  obj-$(CONFIG_I2C_DESIGNWARE_PCI)   += i2c-designware-pci.o
>>  i2c-designware-pci-objs := i2c-designware-pcidrv.o
>>  obj-$(CONFIG_I2C_EG20T)+= i2c-eg20t.o
>> +obj-$(CONFIG_I2C_EXYNOS5)  += i2c-exynos5