is applicable for all generation os Tegra SoC.
IO pads ID and information of bit field for power state and voltage
level controls are added for Tegra124, Tegra132 and Tegra210. The SOR
driver is modified to use the new APIs.
Signed-off-by: Laxman Dewangan
---
Changes from V1:
This is reworked
config
- Make the io pad tables common for all SoC.
- Make io_pads enums.
- Add enums for voltage.
- Drop patch of adding sub devs
Laxman Dewangan (3):
soc/tegra: pmc: Use BIT macro for register field definition
soc/tegra: pmc: Correct type of variable for tegra_pmc_readl()
soc/tegra: pm
config
- Make the io pad tables common for all SoC.
- Make io_pads enums.
- Add enums for voltage.
- Drop patch of adding sub devs
Laxman Dewangan (3):
soc/tegra: pmc: Use BIT macro for register field definition
soc/tegra: pmc: Correct type of variable for tegra_pmc_readl()
soc/tegra: pm
Use BIT macro for register field definition and make constant as U
when using in shift operator like (3 << 30) to (3U << 30)
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
---
Changes from V1:
- Remove the indenting of line which is not for BIT macro usage.
Chang
The function tegra_pmc_readl() returns the u32 type data and hence
change the data type of variable where this data is stored to u32
type.
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
---
Changes from V1:
-This is new in series as per discussion on V1 series to u
Use BIT macro for register field definition and make constant as U
when using in shift operator like (3 << 30) to (3U << 30)
Signed-off-by: Laxman Dewangan
---
Changes from V1:
- Remove the indenting of line which is not for BIT macro usage.
Changes from V2:
- None
---
drivers/soc
The function tegra_pmc_readl() returns the u32 type data and hence
change the data type of variable where this data is stored to u32
type.
Signed-off-by: Laxman Dewangan
---
Changes from V1:
-This is new in series as per discussion on V1 series to use u32 for
tegra_pmc_readl.
Changes from V2
Hi Nishanth,
On Friday 06 May 2016 05:59 AM, Nishanth Menon wrote:
While attempting to try and get each of the regulator nodes of palmas
to be capable of using vin-supply, I noticed a few cleanups and
associated bug fixes.
The series is based on next-20160504 and is split up to aid
readability
Hi Nishanth,
On Friday 06 May 2016 05:59 AM, Nishanth Menon wrote:
While attempting to try and get each of the regulator nodes of palmas
to be capable of using vin-supply, I noticed a few cleanups and
associated bug fixes.
The series is based on next-20160504 and is split up to aid
readability
On Thursday 05 May 2016 07:03 PM, Jon Hunter wrote:
On 05/05/16 14:09, Laxman Dewangan wrote:
On Thursday 05 May 2016 06:38 PM, Jon Hunter wrote:
On 05/05/16 11:32, Laxman Dewangan wrote:
On Thursday 05 May 2016 03:43 PM, Jon Hunter wrote:
On 04/05/16 12:39, Laxman Dewangan wrote
On Thursday 05 May 2016 07:03 PM, Jon Hunter wrote:
On 05/05/16 14:09, Laxman Dewangan wrote:
On Thursday 05 May 2016 06:38 PM, Jon Hunter wrote:
On 05/05/16 11:32, Laxman Dewangan wrote:
On Thursday 05 May 2016 03:43 PM, Jon Hunter wrote:
On 04/05/16 12:39, Laxman Dewangan wrote
On Thursday 05 May 2016 06:38 PM, Jon Hunter wrote:
On 05/05/16 11:32, Laxman Dewangan wrote:
On Thursday 05 May 2016 03:43 PM, Jon Hunter wrote:
On 04/05/16 12:39, Laxman Dewangan wrote:
+return -EINVAL;
+
+for (i = 0; i < soc->num_io_pads; ++i) {
+i
On Thursday 05 May 2016 06:38 PM, Jon Hunter wrote:
On 05/05/16 11:32, Laxman Dewangan wrote:
On Thursday 05 May 2016 03:43 PM, Jon Hunter wrote:
On 04/05/16 12:39, Laxman Dewangan wrote:
+return -EINVAL;
+
+for (i = 0; i < soc->num_io_pads; ++i) {
+i
On Thursday 05 May 2016 06:13 PM, Jon Hunter wrote:
On 05/05/16 10:52, Laxman Dewangan wrote:
On Thursday 05 May 2016 03:19 PM, Jon Hunter wrote:
On 04/05/16 12:39, Laxman Dewangan wrote:
The function tegra_pmc_readl() returns the u32 type data and hence
change the data type of variable
On Thursday 05 May 2016 06:13 PM, Jon Hunter wrote:
On 05/05/16 10:52, Laxman Dewangan wrote:
On Thursday 05 May 2016 03:19 PM, Jon Hunter wrote:
On 04/05/16 12:39, Laxman Dewangan wrote:
The function tegra_pmc_readl() returns the u32 type data and hence
change the data type of variable
On Thursday 05 May 2016 03:43 PM, Jon Hunter wrote:
On 04/05/16 12:39, Laxman Dewangan wrote:
+ return -EINVAL;
+
+ for (i = 0; i < soc->num_io_pads; ++i) {
+ if (soc->io_pads_control[i].pad_id == pad_id)
+ return soc->io_pa
On Thursday 05 May 2016 03:43 PM, Jon Hunter wrote:
On 04/05/16 12:39, Laxman Dewangan wrote:
+ return -EINVAL;
+
+ for (i = 0; i < soc->num_io_pads; ++i) {
+ if (soc->io_pads_control[i].pad_id == pad_id)
+ return soc->io_pa
On Thursday 05 May 2016 03:19 PM, Jon Hunter wrote:
On 04/05/16 12:39, Laxman Dewangan wrote:
The function tegra_pmc_readl() returns the u32 type data and hence
change the data type of variable where this data is stored to u32
type.
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.
On Thursday 05 May 2016 03:19 PM, Jon Hunter wrote:
On 04/05/16 12:39, Laxman Dewangan wrote:
The function tegra_pmc_readl() returns the u32 type data and hence
change the data type of variable where this data is stored to u32
type.
Signed-off-by: Laxman Dewangan
---
Changes from V1
The function tegra_pmc_readl() returns the u32 type data and hence
change the data type of variable where this data is stored to u32
type.
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
---
Changes from V1:
-This is new in series as per discussion on V1 series to u
The function tegra_pmc_readl() returns the u32 type data and hence
change the data type of variable where this data is stored to u32
type.
Signed-off-by: Laxman Dewangan
---
Changes from V1:
-This is new in series as per discussion on V1 series to use u32 for
tegra_pmc_readl.
Changes from V2
the child
devices table for Tegra124 and Tegra210.
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
---
Changes from V1:
Reworked on DT for having flat entry and register all child devices
as simple platform device instead of of_populate_device().
Changes from V2:
- Handling of the r
the child
devices table for Tegra124 and Tegra210.
Signed-off-by: Laxman Dewangan
---
Changes from V1:
Reworked on DT for having flat entry and register all child devices
as simple platform device instead of of_populate_device().
Changes from V2:
- Handling of the release of child devices on error
is applicable for all generation os Tegra SoC.
IO pads ID and information of bit field for power state and voltage
level controls are added for Tegra124, Tegra132 and Tegra210. The sor
driver is modified to use the new APIs.
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
---
Changes f
is applicable for all generation os Tegra SoC.
IO pads ID and information of bit field for power state and voltage
level controls are added for Tegra124, Tegra132 and Tegra210. The sor
driver is modified to use the new APIs.
Signed-off-by: Laxman Dewangan
---
Changes from V1:
This is reworked
Use BIT macro for register field definition and make constant as U
when using in shift operator like (3 << 30) to (3U << 30)
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
---
Changes from V1:
- Remove the indenting of line which is not for BIT macro usage.
Chang
older APIs to configure IO rail and related macros.
Laxman Dewangan (4):
soc/tegra: pmc: Use BIT macro for register field definition
soc/tegra: pmc: Correct type of variable for tegra_pmc_readl()
soc/tegra: pmc: Add support for IO pads power state and voltage
soc/tegra: pmc: Register PMC
Use BIT macro for register field definition and make constant as U
when using in shift operator like (3 << 30) to (3U << 30)
Signed-off-by: Laxman Dewangan
---
Changes from V1:
- Remove the indenting of line which is not for BIT macro usage.
Changes from V2:
- None
---
drivers/soc
older APIs to configure IO rail and related macros.
Laxman Dewangan (4):
soc/tegra: pmc: Use BIT macro for register field definition
soc/tegra: pmc: Correct type of variable for tegra_pmc_readl()
soc/tegra: pmc: Add support for IO pads power state and voltage
soc/tegra: pmc: Register PMC
On Tuesday 03 May 2016 06:42 PM, Jon Hunter wrote:
On 03/05/16 13:48, Laxman Dewangan wrote:
On Tuesday 03 May 2016 06:25 PM, Jon Hunter wrote:
Currently SOR driver is using the tegra_io_rail_power_off/on() APIs.
Once the proper interface available then I will move sor driver to use
new
On Tuesday 03 May 2016 06:42 PM, Jon Hunter wrote:
On 03/05/16 13:48, Laxman Dewangan wrote:
On Tuesday 03 May 2016 06:25 PM, Jon Hunter wrote:
Currently SOR driver is using the tegra_io_rail_power_off/on() APIs.
Once the proper interface available then I will move sor driver to use
new
On Tuesday 03 May 2016 06:14 PM, Jon Hunter wrote:
On 02/05/16 13:17, Laxman Dewangan wrote:
+
+The voltage supported on the pads are 1.8V and 3.3V. The enums are defined as:
+ For 1.8V, use TEGRA_IO_PAD_POWER_SOURCE_180UV
+ For 3.3V, use TEGRA_IO_PAD_POWER_SOURCE_330UV
On Tuesday 03 May 2016 06:14 PM, Jon Hunter wrote:
On 02/05/16 13:17, Laxman Dewangan wrote:
+
+The voltage supported on the pads are 1.8V and 3.3V. The enums are defined as:
+ For 1.8V, use TEGRA_IO_PAD_POWER_SOURCE_180UV
+ For 3.3V, use TEGRA_IO_PAD_POWER_SOURCE_330UV
On Tuesday 03 May 2016 06:25 PM, Jon Hunter wrote:
Currently SOR driver is using the tegra_io_rail_power_off/on() APIs.
Once the proper interface available then I will move sor driver to use
new method and then we can full get rid of older APIs and macros.
Till that, we need to have this.
On Tuesday 03 May 2016 06:25 PM, Jon Hunter wrote:
Currently SOR driver is using the tegra_io_rail_power_off/on() APIs.
Once the proper interface available then I will move sor driver to use
new method and then we can full get rid of older APIs and macros.
Till that, we need to have this.
On Tuesday 03 May 2016 06:04 PM, Jon Hunter wrote:
On 02/05/16 13:17, Laxman Dewangan wrote:
+
+ return tegra_io_rail_power_on(dpd_bit);
From a readability standpoint the above seems weird because
tegra_io_pads_power_enable() takes an ID as the argument, translates it
to a bit value
On Tuesday 03 May 2016 06:04 PM, Jon Hunter wrote:
On 02/05/16 13:17, Laxman Dewangan wrote:
+
+ return tegra_io_rail_power_on(dpd_bit);
From a readability standpoint the above seems weird because
tegra_io_pads_power_enable() takes an ID as the argument, translates it
to a bit value
liked it.
Acked-by: Laxman Dewangan <ldewan...@nvidia.com>
On Sunday 01 May 2016 04:06 PM, Masahiro Yamada wrote:
Add a device managed API for reset_controller_register().
This helps in reducing code in .remove callbacks and sometimes
dropping .remove callbacks entirely.
Signed-off-by: Masahiro Yamada
I liked it.
Acked-by: Laxman Dewangan
On Tuesday 03 May 2016 12:14 AM, Stephen Warren wrote:
On 05/02/2016 11:58 AM, Laxman Dewangan wrote:
Toggling OE bit is something emulating the open drain here.
From the perspective of the external HW that's attached to the GPIO, I
believe there's no difference.
I think idea
On Tuesday 03 May 2016 12:14 AM, Stephen Warren wrote:
On 05/02/2016 11:58 AM, Laxman Dewangan wrote:
Toggling OE bit is something emulating the open drain here.
From the perspective of the external HW that's attached to the GPIO, I
believe there's no difference.
I think idea
same as other fields of mux
registers.
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
---
Changes from V1:
- Only check if parked_bit is >=0 for validity.
drivers/pinctrl/tegra/pinctrl-tegra.c| 8
drivers/pinctrl/tegra/pinctrl-tegra.h| 6 +-
drivers/pinc
same as other fields of mux
registers.
Signed-off-by: Laxman Dewangan
---
Changes from V1:
- Only check if parked_bit is >=0 for validity.
drivers/pinctrl/tegra/pinctrl-tegra.c| 8
drivers/pinctrl/tegra/pinctrl-tegra.h| 6 +-
drivers/pinctrl/tegra/pinctrl-tegra114.c
On Monday 02 May 2016 08:37 PM, Rhyland Klein wrote:
On 5/2/2016 10:28 AM, Laxman Dewangan wrote:
NVIDIA's Tegra210 support the park bit to make pinmux configuration
enable/disable. If parked bit is 1 then configuration does not apply
and if it is 0 then pinmux configuration applies
On Monday 02 May 2016 08:37 PM, Rhyland Klein wrote:
On 5/2/2016 10:28 AM, Laxman Dewangan wrote:
NVIDIA's Tegra210 support the park bit to make pinmux configuration
enable/disable. If parked bit is 1 then configuration does not apply
and if it is 0 then pinmux configuration applies
On Monday 02 May 2016 09:42 PM, Stephen Warren wrote:
On 04/30/2016 05:07 AM, Linus Walleij wrote:
On Fri, Apr 29, 2016 at 11:20 AM, Laxman Dewangan
<ldewan...@nvidia.com> wrote:
On Friday 29 April 2016 02:37 PM, Linus Walleij wrote:
On Mon, Apr 25, 2016 at 12:38 PM, Laxman Dewangan
&
On Monday 02 May 2016 09:42 PM, Stephen Warren wrote:
On 04/30/2016 05:07 AM, Linus Walleij wrote:
On Fri, Apr 29, 2016 at 11:20 AM, Laxman Dewangan
wrote:
On Friday 29 April 2016 02:37 PM, Linus Walleij wrote:
On Mon, Apr 25, 2016 at 12:38 PM, Laxman Dewangan
wrote:
Add support
fig */
}
But in this case, bit is s8 and hence for non supporting it is -1.
Correct the check as:
if (bit < 0) {
/* Not supported config */
}
Fixes: e4c02dced975cb ("pinctrl: tegra: use signed bitfields for optional
fields")
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
fig */
}
But in this case, bit is s8 and hence for non supporting it is -1.
Correct the check as:
if (bit < 0) {
/* Not supported config */
}
Fixes: e4c02dced975cb ("pinctrl: tegra: use signed bitfields for optional
fields")
Signed-off-by: Laxman Dewangan
---
drivers/pinctrl/tegra/pin
same as other fields of mux
registers.
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
---
drivers/pinctrl/tegra/pinctrl-tegra.c| 8
drivers/pinctrl/tegra/pinctrl-tegra.h| 6 +-
drivers/pinctrl/tegra/pinctrl-tegra114.c | 4 ++--
drivers/pinctrl/tegra/pinctrl-tegr
ted */
}
But in this case, bit is s8 and hence for non supporting it is -1.
Correct the check as:
if (bit < 0 || bit > 31) {
/* Not supported */
}
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
---
I think it should go on stable.
drivers/pinctrl/tegra/pinctrl-tegra.c | 2 +-
1 file chang
same as other fields of mux
registers.
Signed-off-by: Laxman Dewangan
---
drivers/pinctrl/tegra/pinctrl-tegra.c| 8
drivers/pinctrl/tegra/pinctrl-tegra.h| 6 +-
drivers/pinctrl/tegra/pinctrl-tegra114.c | 4 ++--
drivers/pinctrl/tegra/pinctrl-tegra124.c | 4 ++--
drivers
ted */
}
But in this case, bit is s8 and hence for non supporting it is -1.
Correct the check as:
if (bit < 0 || bit > 31) {
/* Not supported */
}
Signed-off-by: Laxman Dewangan
---
I think it should go on stable.
drivers/pinctrl/tegra/pinctrl-tegra.c | 2 +-
1 file changed, 1 insertion(+), 1
binding document for detailing the DT properties for
configuring IO pads voltage levels and its power state.
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
---
Changes from V1:
- Reworked on DT properties to use generic pinconf DT. Also add macros
for voltage support. Now all DT prop
the child
devices table for Tegra210.
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
---
Changes from V1:
Reworked on DT for having flat entry and register all child devices
as simple platform device instead of of_populate_device().
---
drivers/soc/tegra/pmc.
.
The voltage and power state configurations of pads are provided
through pin control frameworks. Add pin control driver for Tegra's
IO pads' voltage and power state configurations.
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
---
Changes from V1:
- Use the generic pincontrol property for low
binding document for detailing the DT properties for
configuring IO pads voltage levels and its power state.
Signed-off-by: Laxman Dewangan
---
Changes from V1:
- Reworked on DT properties to use generic pinconf DT. Also add macros
for voltage support. Now all DT properties are in flat DT instead
the child
devices table for Tegra210.
Signed-off-by: Laxman Dewangan
---
Changes from V1:
Reworked on DT for having flat entry and register all child devices
as simple platform device instead of of_populate_device().
---
drivers/soc/tegra/pmc.c | 54
.
The voltage and power state configurations of pads are provided
through pin control frameworks. Add pin control driver for Tegra's
IO pads' voltage and power state configurations.
Signed-off-by: Laxman Dewangan
---
Changes from V1:
- Use the generic pincontrol property for low power enable/disable.
- sync
and information of bit field for power state and voltage
level controls are added for Tegra210.
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
---
Changes from V1:
This is reworked on earlier path to have separation between IO rails and
io pads and add power state and voltage contro
and information of bit field for power state and voltage
level controls are added for Tegra210.
Signed-off-by: Laxman Dewangan
---
Changes from V1:
This is reworked on earlier path to have separation between IO rails and
io pads and add power state and voltage control APIs in single call.
---
drivers
Use BIT macro for register field definition and make constant as U
when using in shift operator like (3 << 30) to (3U << 30)
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
---
Changes from V1:
- Remove the indenting of line which is not for BIT macro usage.
---
drive
pads voltage and power state.
---
Changes from V1:
- Use pinconfig generic property for power enable/disable.
- Rename power-source-voltage properties.
- Make all register read/write value to u32.
- Add IO pads macros and APIs which is nearest definiton of HW blocks.
Laxman Dewangan (6):
soc/tegra
The function tegra_pmc_readl() returns the u32 type data and hence
change the data type of variable where this data is stored to u32
type.
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
---
Changes from V1:
-This is new in series as per discussion on V1 series to u
Use BIT macro for register field definition and make constant as U
when using in shift operator like (3 << 30) to (3U << 30)
Signed-off-by: Laxman Dewangan
---
Changes from V1:
- Remove the indenting of line which is not for BIT macro usage.
---
drivers/soc/tegr
pads voltage and power state.
---
Changes from V1:
- Use pinconfig generic property for power enable/disable.
- Rename power-source-voltage properties.
- Make all register read/write value to u32.
- Add IO pads macros and APIs which is nearest definiton of HW blocks.
Laxman Dewangan (6):
soc/tegra
The function tegra_pmc_readl() returns the u32 type data and hence
change the data type of variable where this data is stored to u32
type.
Signed-off-by: Laxman Dewangan
---
Changes from V1:
-This is new in series as per discussion on V1 series to use u32 for
tegra_pmc_readl.
---
drivers/soc
On Saturday 30 April 2016 04:37 PM, Linus Walleij wrote:
On Fri, Apr 29, 2016 at 11:20 AM, Laxman Dewangan <ldewan...@nvidia.com> wrote:
On Friday 29 April 2016 02:37 PM, Linus Walleij wrote:
On Mon, Apr 25, 2016 at 12:38 PM, Laxman Dewangan <ldewan...@nvidia.com>
wrote:
On Saturday 30 April 2016 04:37 PM, Linus Walleij wrote:
On Fri, Apr 29, 2016 at 11:20 AM, Laxman Dewangan wrote:
On Friday 29 April 2016 02:37 PM, Linus Walleij wrote:
On Mon, Apr 25, 2016 at 12:38 PM, Laxman Dewangan
wrote:
Add support for the debounce as Tegra210 support debounce in HW
On Saturday 30 April 2016 05:08 PM, Linus Walleij wrote:
On Thu, Apr 28, 2016 at 11:59 AM, Laxman Dewangan <ldewan...@nvidia.com> wrote:
MAXIM Semiconductor's PMIC, MAX77620/MAX20024 has 8 GPIO
pins. It also supports interrupts from these pins.
Add GPIO driver for these pins to contr
On Saturday 30 April 2016 05:08 PM, Linus Walleij wrote:
On Thu, Apr 28, 2016 at 11:59 AM, Laxman Dewangan wrote:
MAXIM Semiconductor's PMIC, MAX77620/MAX20024 has 8 GPIO
pins. It also supports interrupts from these pins.
Add GPIO driver for these pins to control via GPIO APIs.
Signed-off
Implement gpio_get_direction() callback for Tegra GPIO.
The direction is only valid if the pin is configured as
GPIO. If pin is not configured in GPIO mode then this
function return error.
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
---
This patch is based on discussion on ser
Implement gpio_get_direction() callback for Tegra GPIO.
The direction is only valid if the pin is configured as
GPIO. If pin is not configured in GPIO mode then this
function return error.
Signed-off-by: Laxman Dewangan
---
This patch is based on discussion on series
Re: [PATCH V5 0/4] gpio
Implement gpio_get_direction() callback for Tegra GPIO.
The direction is only valid if the pin is configured as
GPIO. If pin is not configured in GPIO mode then this
function return error.
This makes debugfs and initial reading of the state of
the lines more accurate.
Signed-off-by: Laxman
Implement gpio_get_direction() callback for Tegra GPIO.
The direction is only valid if the pin is configured as
GPIO. If pin is not configured in GPIO mode then this
function return error.
This makes debugfs and initial reading of the state of
the lines more accurate.
Signed-off-by: Laxman
On Friday 29 April 2016 02:37 PM, Linus Walleij wrote:
On Mon, Apr 25, 2016 at 12:38 PM, Laxman Dewangan <ldewan...@nvidia.com> wrote:
Add support for the debounce as Tegra210 support debounce in HW.
Also do the clenaups to remove all global variables.
OK this v5 is applied.
Laxma
On Friday 29 April 2016 02:37 PM, Linus Walleij wrote:
On Mon, Apr 25, 2016 at 12:38 PM, Laxman Dewangan wrote:
Add support for the debounce as Tegra210 support debounce in HW.
Also do the clenaups to remove all global variables.
OK this v5 is applied.
Laxman does this GPIO also have open
Hi Lee,
On Thursday 28 April 2016 03:28 PM, Laxman Dewangan wrote:
MAXIM Semiconductor's PMIC, MAX77620/MAX20024 has 8 GPIO pins
which also act as the special function in alternate mode. Also
there is configuration like push-pull, open drain, FPS timing
etc for these pins.
Add pin control
Hi Lee,
On Thursday 28 April 2016 03:28 PM, Laxman Dewangan wrote:
MAXIM Semiconductor's PMIC, MAX77620/MAX20024 has 8 GPIO pins
which also act as the special function in alternate mode. Also
there is configuration like push-pull, open drain, FPS timing
etc for these pins.
Add pin control
On Thursday 28 April 2016 02:31 PM, Lee Jones wrote:
On Mon, 25 Apr 2016, Krzysztof Kozlowski wrote:
On 04/21/2016 02:25 PM, Laxman Dewangan wrote:
Use devm_mfd_add_devices() for adding MFD child devices and
devm_regmap_add_irq_chip() for IRQ chip registration.
This reduces the error code
On Thursday 28 April 2016 02:31 PM, Lee Jones wrote:
On Mon, 25 Apr 2016, Krzysztof Kozlowski wrote:
On 04/21/2016 02:25 PM, Laxman Dewangan wrote:
Use devm_mfd_add_devices() for adding MFD child devices and
devm_regmap_add_irq_chip() for IRQ chip registration.
This reduces the error code
Maxim Semiconductor's PMIC MAX77620/MAX20024 has 8 GPIO pins
which act as GPIO as well as special function mode.
Add DT binding document to configure pins in function mode as
well as pin configuration parameters.
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
Acked-by: Rob Herr
Maxim Semiconductor's PMIC MAX77620/MAX20024 has 8 GPIO pins
which act as GPIO as well as special function mode.
Add DT binding document to support these pins in GPIO
mode via GPIO framework.
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
Acked-by: Rob Herring <r...@kernel.o
Maxim Semiconductor's PMIC MAX77620/MAX20024 has 8 GPIO pins
which act as GPIO as well as special function mode.
Add DT binding document to configure pins in function mode as
well as pin configuration parameters.
Signed-off-by: Laxman Dewangan
Acked-by: Rob Herring
Acked-by: Linus Walleij
Maxim Semiconductor's PMIC MAX77620/MAX20024 has 8 GPIO pins
which act as GPIO as well as special function mode.
Add DT binding document to support these pins in GPIO
mode via GPIO framework.
Signed-off-by: Laxman Dewangan
Acked-by: Rob Herring
Acked-by: Linus Walleij
---
Changes from V4
-by: Laxman Dewangan <ldewan...@nvidia.com>
Reviewed-by: Linus Walleij <linus.wall...@linaro.org>
---
Changes from V1:
- Cleanup code based on comment received on mfd/rtc.
- Avoid duplication on error message.
Changes form V2:
- Run coccicheck and checkpatch in strict mode for t
-by: Laxman Dewangan
Reviewed-by: Linus Walleij
---
Changes from V1:
- Cleanup code based on comment received on mfd/rtc.
- Avoid duplication on error message.
Changes form V2:
- Run coccicheck and checkpatch in strict mode for the alignment.
- update based on api changes from core.
Changes
MAXIM Semiconductor's PMIC, MAX77620/MAX20024 has 8 GPIO
pins. It also supports interrupts from these pins.
Add GPIO driver for these pins to control via GPIO APIs.
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
Reviewed-by: Linus Walleij <linus.wall...@linaro.org>
---
Cha
MAXIM Semiconductor's PMIC, MAX77620/MAX20024 has 8 GPIO
pins. It also supports interrupts from these pins.
Add GPIO driver for these pins to control via GPIO APIs.
Signed-off-by: Laxman Dewangan
Reviewed-by: Linus Walleij
---
Changes from V1:
- Use the gpiochip_add_data and get the chip data
The MAXIM PMIC MAX77620 and MAX20024 are power management IC
which supports RTC, GPIO, DCDC/LDO regulators, interrupt,
watchdog etc.
Add DT binding document for the different functionality of
this device.
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
Acked-by: Rob Herr
The MAXIM PMIC MAX77620 and MAX20024 are power management IC
which supports RTC, GPIO, DCDC/LDO regulators, interrupt,
watchdog etc.
Add DT binding document for the different functionality of
this device.
Signed-off-by: Laxman Dewangan
Acked-by: Rob Herring
---
Changes from V1:
- Added units
of the device.
Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com>
Signed-off-by: Mallikarjun Kasoju <mkas...@nvidia.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
---
Changes from V1:
- Code cleanups per review from V1.
- Move register acccess APIs from header t
of the device.
Signed-off-by: Laxman Dewangan
Signed-off-by: Mallikarjun Kasoju
Reviewed-by: Krzysztof Kozlowski
---
Changes from V1:
- Code cleanups per review from V1.
- Move register acccess APIs from header to c file.
- Remove some of non required variable, remove duplication in error message
/warning.
Changes from V9:
Use devm_regmap_add_irq_chip() and devm_gpiochip_add_data()
Changes from V10:
Use devm_mfd*, document FPS and soem apis, correct error message in mfd patch.
Laxman Dewangan (6):
mfd: add device-tree binding doc for PMIC max77620/max20024
mfd: max77620: add core driver
/warning.
Changes from V9:
Use devm_regmap_add_irq_chip() and devm_gpiochip_add_data()
Changes from V10:
Use devm_mfd*, document FPS and soem apis, correct error message in mfd patch.
Laxman Dewangan (6):
mfd: add device-tree binding doc for PMIC max77620/max20024
mfd: max77620: add core driver
On Thursday 28 April 2016 12:55 PM, Lee Jones wrote:
On Wed, 27 Apr 2016, Laxman Dewangan wrote:
On Wednesday 27 April 2016 08:49 PM, Lee Jones wrote:
On Wed, 30 Mar 2016, Laxman Dewangan wrote:
+#define MAX77620_MFD_CELL_RES(_name, _res
On Thursday 28 April 2016 12:55 PM, Lee Jones wrote:
On Wed, 27 Apr 2016, Laxman Dewangan wrote:
On Wednesday 27 April 2016 08:49 PM, Lee Jones wrote:
On Wed, 30 Mar 2016, Laxman Dewangan wrote:
+#define MAX77620_MFD_CELL_RES(_name, _res
On Wednesday 27 April 2016 08:49 PM, Lee Jones wrote:
On Wed, 30 Mar 2016, Laxman Dewangan wrote:
What are 20 and 40? I think you're going to need a comment to
describe what's going on in this function.
+ int x, i;
+
+ for (i = 0; i < 0x7; i++) {
It's unsual to use hex val
On Wednesday 27 April 2016 08:49 PM, Lee Jones wrote:
On Wed, 30 Mar 2016, Laxman Dewangan wrote:
What are 20 and 40? I think you're going to need a comment to
describe what's going on in this function.
+ int x, i;
+
+ for (i = 0; i < 0x7; i++) {
It's unsual to use hex val
On Wednesday 27 April 2016 08:49 PM, Lee Jones wrote:
On Wed, 30 Mar 2016, Laxman Dewangan wrote:
+#define MAX77620_MFD_CELL_RES(_name, _res) \
+ { \
+ .name = (_name
501 - 600 of 3619 matches
Mail list logo
