Re: Re: [PATCH v4 0/7] Add TI EMIF SDRAM controller driver

Re: Re: [PATCH v4 0/7] Add TI EMIF SDRAM controller driver

[함명주]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=euc-kr, Size: 4974 bytes --]


Kyungmin Park<kmpark@infradead.org> 2012-03-17 15:10 (GMT+09:00)
> Hi,
> On 3/17/12, Aneesh V wrote:
> > Add a driver for the EMIF SDRAM controller used in TI SoCs
> >
> > EMIF is an SDRAM controller that supports, based on its revision,
> > one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support
> > for LPDDR2.
> >
> > The driver supports the following features:
> > - Calculates the DDR AC timing parameters to be set in EMIF
> >   registers using data from the device data-sheets and based
> >   on the DDR frequency. If data from data-sheets is not available
> >   default timing values from the JEDEC spec are used. These
> >   will be safe, but not necessarily optimal
> > - API for changing timings during DVFS or at boot-up

This means that you alreeady have callbacks to create a devfreq device driver that supports DVFS on the device. This doesn't need to be a misc device driver then.

> > - Temperature alert configuration and handling of temperature
> >   alerts, if any for LPDDR2 devices
> >   * temperature alert is based on periodic polling of MR4 mode
> >     register in DDR devices automatically performed by hardware
> >   * timings are de-rated and brought back to nominal when
> >     temperature raises and falls respectively

This can be a feature overriding "max_freq" inside the Omap EMIF devfreq device driver though it maybe (or not.. I just don't sure) be better to use thermal framework as well.


Cheers!
MyungJoo

> > - Cache of calculated register values to avoid re-calculating
> >   them
> >
> > The driver will need some minor updates when it is eventually
> > integrated with Dynamic Voltage and Frequency Scaling (DVFS).
> > This can not be done now as DVFS support is not available in
> > the mainline yet.
> Do you see the devfreq? it's designed for non-cpu device frequency.
> It's role is similar with cpufreq.
> 
> Now samsung exynos uses devfreq for DRAM bus frequency.
> 
> Thank you,
> Kyungmin Park
> >
> > Discussions with Santosh Shilimkar 
> > were immensely helpful in shaping up the interfaces. Vibhore Vardhan
> > did the initial code snippet for thermal
> > handling.
> >
> > Testing:
> > - The driver is tested on OMAP4430 SDP.
> > - The driver in a slightly adapted form is also tested on OMAP5.
> > - Since mainline kernel doesn't have DVFS support yet,
> >   testing was done using a test module.
> > - Temperature alert handling was tested with simulated interrupts
> >   and faked temperature values as testing all cases in real-life
> >   scenarios is difficult.
> > - Tested the driver as a module
> >
> > Cc: Greg KH 
> >
> > v4:
> > - Converted instances of EXPORT_SYMBOL to EXPORT_SYMBOL_GPL
> > - Removed un-necessary "#ifndef __ASSEMBLY__'
> > - Minor formatting fix
> >
> > v2:
> > - Fixed a bug found in the implementation of errata i728
> >   workaround
> > - Fixed the value of frequency printed in debugfs
> > - Dropped the hwmod patch as Paul has already posted a
> >   a hwmod series [1] that adds hwmod for EMIF
> > - Converted instances of __init to __init_or_module
> >
> > [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/72855
> >
> > Aneesh V (7):
> >   misc: ddr: add LPDDR2 data from JESD209-2
> >   misc: emif: add register definitions for EMIF
> >   misc: emif: add basic infrastructure for EMIF driver
> >   misc: emif: handle frequency and voltage change events
> >   misc: emif: add interrupt and temperature handling
> >   misc: emif: add one-time settings
> >   misc: emif: add debugfs entries for emif
> >
> >  Documentation/misc-devices/ti-emif.txt  |   58 ++
> >  drivers/misc/Kconfig                    |   12 +
> >  drivers/misc/Makefile                   |    1 +
> >  drivers/misc/emif.c                     | 1670
> > +++++++++++++++++++++++++++++++
> >  drivers/misc/emif.h                     |  589 +++++++++++
> >  include/linux/platform_data/emif_plat.h |  128 +++
> >  include/misc/jedec_ddr.h                |  175 ++++
> >  lib/Kconfig                             |    8 +
> >  lib/Makefile                            |    2 +
> >  lib/jedec_ddr_data.c                    |  135 +++
> >  10 files changed, 2778 insertions(+), 0 deletions(-)
> >  create mode 100644 Documentation/misc-devices/ti-emif.txt
> >  create mode 100644 drivers/misc/emif.c
> >  create mode 100644 drivers/misc/emif.h
> >  create mode 100644 include/linux/platform_data/emif_plat.h
> >  create mode 100644 include/misc/jedec_ddr.h
> >  create mode 100644 lib/jedec_ddr_data.c
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
> 

--
MyungJoo Ham (ÇÔ¸íÁÖ), PHD
System S/W Lab, S/W Platform Team, Software Center
Samsung Electronics
Cell: +82-10-6714-2858



 

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: Re: [PATCH v4 0/7] Add TI EMIF SDRAM controller driver

[함명주]

Kyungmin Park<kmpark@infradead.org> 2012-03-17 15:10 (GMT+09:00)
> Hi,
> On 3/17/12, Aneesh V wrote:
> > Add a driver for the EMIF SDRAM controller used in TI SoCs
> >
> > EMIF is an SDRAM controller that supports, based on its revision,
> > one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support
> > for LPDDR2.
> >
> > The driver supports the following features:
> > - Calculates the DDR AC timing parameters to be set in EMIF
> >   registers using data from the device data-sheets and based
> >   on the DDR frequency. If data from data-sheets is not available
> >   default timing values from the JEDEC spec are used. These
> >   will be safe, but not necessarily optimal
> > - API for changing timings during DVFS or at boot-up

This means that you alreeady have callbacks to create a devfreq device driver that supports DVFS on the device. This doesn't need to be a misc device driver then.

> > - Temperature alert configuration and handling of temperature
> >   alerts, if any for LPDDR2 devices
> >   * temperature alert is based on periodic polling of MR4 mode
> >     register in DDR devices automatically performed by hardware
> >   * timings are de-rated and brought back to nominal when
> >     temperature raises and falls respectively

This can be a feature overriding "max_freq" inside the Omap EMIF devfreq device driver though it maybe (or not.. I just don't sure) be better to use thermal framework as well.


Cheers!
MyungJoo

> > - Cache of calculated register values to avoid re-calculating
> >   them
> >
> > The driver will need some minor updates when it is eventually
> > integrated with Dynamic Voltage and Frequency Scaling (DVFS).
> > This can not be done now as DVFS support is not available in
> > the mainline yet.
> Do you see the devfreq? it's designed for non-cpu device frequency.
> It's role is similar with cpufreq.
> 
> Now samsung exynos uses devfreq for DRAM bus frequency.
> 
> Thank you,
> Kyungmin Park
> >
> > Discussions with Santosh Shilimkar 
> > were immensely helpful in shaping up the interfaces. Vibhore Vardhan
> > did the initial code snippet for thermal
> > handling.
> >
> > Testing:
> > - The driver is tested on OMAP4430 SDP.
> > - The driver in a slightly adapted form is also tested on OMAP5.
> > - Since mainline kernel doesn't have DVFS support yet,
> >   testing was done using a test module.
> > - Temperature alert handling was tested with simulated interrupts
> >   and faked temperature values as testing all cases in real-life
> >   scenarios is difficult.
> > - Tested the driver as a module
> >
> > Cc: Greg KH 
> >
> > v4:
> > - Converted instances of EXPORT_SYMBOL to EXPORT_SYMBOL_GPL
> > - Removed un-necessary "#ifndef __ASSEMBLY__'
> > - Minor formatting fix
> >
> > v2:
> > - Fixed a bug found in the implementation of errata i728
> >   workaround
> > - Fixed the value of frequency printed in debugfs
> > - Dropped the hwmod patch as Paul has already posted a
> >   a hwmod series [1] that adds hwmod for EMIF
> > - Converted instances of __init to __init_or_module
> >
> > [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/72855
> >
> > Aneesh V (7):
> >   misc: ddr: add LPDDR2 data from JESD209-2
> >   misc: emif: add register definitions for EMIF
> >   misc: emif: add basic infrastructure for EMIF driver
> >   misc: emif: handle frequency and voltage change events
> >   misc: emif: add interrupt and temperature handling
> >   misc: emif: add one-time settings
> >   misc: emif: add debugfs entries for emif
> >
> >  Documentation/misc-devices/ti-emif.txt  |   58 ++
> >  drivers/misc/Kconfig                    |   12 +
> >  drivers/misc/Makefile                   |    1 +
> >  drivers/misc/emif.c                     | 1670
> > +++++++++++++++++++++++++++++++
> >  drivers/misc/emif.h                     |  589 +++++++++++
> >  include/linux/platform_data/emif_plat.h |  128 +++
> >  include/misc/jedec_ddr.h                |  175 ++++
> >  lib/Kconfig                             |    8 +
> >  lib/Makefile                            |    2 +
> >  lib/jedec_ddr_data.c                    |  135 +++
> >  10 files changed, 2778 insertions(+), 0 deletions(-)
> >  create mode 100644 Documentation/misc-devices/ti-emif.txt
> >  create mode 100644 drivers/misc/emif.c
> >  create mode 100644 drivers/misc/emif.h
> >  create mode 100644 include/linux/platform_data/emif_plat.h
> >  create mode 100644 include/misc/jedec_ddr.h
> >  create mode 100644 lib/jedec_ddr_data.c
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
> 

--
MyungJoo Ham (함명주), PHD
System S/W Lab, S/W Platform Team, Software Center
Samsung Electronics
Cell: +82-10-6714-2858



 

Re: Re: [PATCH v4 0/7] Add TI EMIF SDRAM controller driver

[Shilimkar, Santosh]

2012/3/19 함명주 <myungjoo.ham@samsung.com>:
>
> Kyungmin Park<kmpark@infradead.org> 2012-03-17 15:10 (GMT+09:00)
>> Hi,
>> On 3/17/12, Aneesh V wrote:
>> > Add a driver for the EMIF SDRAM controller used in TI SoCs
>> >
>> > EMIF is an SDRAM controller that supports, based on its revision,
>> > one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support
>> > for LPDDR2.
>> >
>> > The driver supports the following features:
>> > - Calculates the DDR AC timing parameters to be set in EMIF
>> >   registers using data from the device data-sheets and based
>> >   on the DDR frequency. If data from data-sheets is not available
>> >   default timing values from the JEDEC spec are used. These
>> >   will be safe, but not necessarily optimal
>> > - API for changing timings during DVFS or at boot-up
>
> This means that you alreeady have callbacks to create a devfreq device driver that supports DVFS on the device. This doesn't need to be a misc device driver then.
>
Nope. The callbacks mentioned above are mainly coming from the clock
framework. Ofcourse the clock node trigger
with voltage ramps would be triggered by some upper laver
governor/framework like CPUFreq/DEVFREQ but as
such this is not necessary. This is an indepdent driver and just like
CPUFREQ notifies it's users for the frequency
change, this driver will be notified to take any action on pre and
post notification. Note that, the driver will
be notified by regulator framework for the voltage ramp up/down cases
too with notifiers.

>> > - Temperature alert configuration and handling of temperature
>> >   alerts, if any for LPDDR2 devices
>> >   * temperature alert is based on periodic polling of MR4 mode
>> >     register in DDR devices automatically performed by hardware
>> >   * timings are de-rated and brought back to nominal when
>> >     temperature raises and falls respectively
>
> This can be a feature overriding "max_freq" inside the Omap EMIF devfreq device driver though it maybe (or not.. I just don't sure) be better to use thermal framework as well.
>
That's absolute abuse and there is no need to link the temperature
handling with DVFS. Reducing frequency can be one
of the cooling techniques but that's not related to the temperature
alert handling. Temperature handling in the EMIF
driver is strictly as per the JDEC specs and that is to de-rate the
timings when temperature threshold is crossed.

The idea is drivers should be independent of all the global policy
governors. Hope this is clear to
you.

Regards
Santosh

Re: Re: [PATCH v4 0/7] Add TI EMIF SDRAM controller driver

[Shilimkar, Santosh]

2012/3/19 함명주 <myungjoo.ham@samsung.com>:
>
> Kyungmin Park<kmpark@infradead.org> 2012-03-17 15:10 (GMT+09:00)
>> Hi,
>> On 3/17/12, Aneesh V wrote:
>> > Add a driver for the EMIF SDRAM controller used in TI SoCs
>> >
>> > EMIF is an SDRAM controller that supports, based on its revision,
>> > one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support
>> > for LPDDR2.
>> >
>> > The driver supports the following features:
>> > - Calculates the DDR AC timing parameters to be set in EMIF
>> >   registers using data from the device data-sheets and based
>> >   on the DDR frequency. If data from data-sheets is not available
>> >   default timing values from the JEDEC spec are used. These
>> >   will be safe, but not necessarily optimal
>> > - API for changing timings during DVFS or at boot-up
>
> This means that you alreeady have callbacks to create a devfreq device driver that supports DVFS on the device. This doesn't need to be a misc device driver then.
>
Nope. The callbacks mentioned above are mainly coming from the clock
framework. Ofcourse the clock node trigger
with voltage ramps would be triggered by some upper laver
governor/framework like CPUFreq/DEVFREQ but as
such this is not necessary. This is an indepdent driver and just like
CPUFREQ notifies it's users for the frequency
change, this driver will be notified to take any action on pre and
post notification. Note that, the driver will
be notified by regulator framework for the voltage ramp up/down cases
too with notifiers.

>> > - Temperature alert configuration and handling of temperature
>> >   alerts, if any for LPDDR2 devices
>> >   * temperature alert is based on periodic polling of MR4 mode
>> >     register in DDR devices automatically performed by hardware
>> >   * timings are de-rated and brought back to nominal when
>> >     temperature raises and falls respectively
>
> This can be a feature overriding "max_freq" inside the Omap EMIF devfreq device driver though it maybe (or not.. I just don't sure) be better to use thermal framework as well.
>
That's absolute abuse and there is no need to link the temperature
handling with DVFS. Reducing frequency can be one
of the cooling techniques but that's not related to the temperature
alert handling. Temperature handling in the EMIF
driver is strictly as per the JDEC specs and that is to de-rate the
timings when temperature threshold is crossed.

The idea is drivers should be independent of all the global policy
governors. Hope this is clear to
you.

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

[PATCH v4 0/7] Add TI EMIF SDRAM controller driver

[Shilimkar, Santosh]

2012/3/19 ??? <myungjoo.ham@samsung.com>:
>
> Kyungmin Park<kmpark@infradead.org> 2012-03-17 15:10 (GMT+09:00)
>> Hi,
>> On 3/17/12, Aneesh V wrote:
>> > Add a driver for the EMIF SDRAM controller used in TI SoCs
>> >
>> > EMIF is an SDRAM controller that supports, based on its revision,
>> > one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support
>> > for LPDDR2.
>> >
>> > The driver supports the following features:
>> > - Calculates the DDR AC timing parameters to be set in EMIF
>> >   registers using data from the device data-sheets and based
>> >   on the DDR frequency. If data from data-sheets is not available
>> >   default timing values from the JEDEC spec are used. These
>> >   will be safe, but not necessarily optimal
>> > - API for changing timings during DVFS or at boot-up
>
> This means that you alreeady have callbacks to create a devfreq device driver that supports DVFS on the device. This doesn't need to be a misc device driver then.
>
Nope. The callbacks mentioned above are mainly coming from the clock
framework. Ofcourse the clock node trigger
with voltage ramps would be triggered by some upper laver
governor/framework like CPUFreq/DEVFREQ but as
such this is not necessary. This is an indepdent driver and just like
CPUFREQ notifies it's users for the frequency
change, this driver will be notified to take any action on pre and
post notification. Note that, the driver will
be notified by regulator framework for the voltage ramp up/down cases
too with notifiers.

>> > - Temperature alert configuration and handling of temperature
>> >   alerts, if any for LPDDR2 devices
>> >   * temperature alert is based on periodic polling of MR4 mode
>> >     register in DDR devices automatically performed by hardware
>> >   * timings are de-rated and brought back to nominal when
>> >     temperature raises and falls respectively
>
> This can be a feature overriding "max_freq" inside the Omap EMIF devfreq device driver though it maybe (or not.. I just don't sure) be better to use thermal framework as well.
>
That's absolute abuse and there is no need to link the temperature
handling with DVFS. Reducing frequency can be one
of the cooling techniques but that's not related to the temperature
alert handling. Temperature handling in the EMIF
driver is strictly as per the JDEC specs and that is to de-rate the
timings when temperature threshold is crossed.

The idea is drivers should be independent of all the global policy
governors. Hope this is clear to
you.

Regards
Santosh