Re: [PATCH 2/2] pwm: bcm-kona: apply pwm settings on enable

On Thu, Nov 8, 2018 at 2:59 AM Uwe Kleine-König wrote: > > Hello, > > adding Tim Kryger as the initial author of the bcm-kona driver to Cc:. > Maybe he can shed some light to the questions below? > > On Thu, Nov 08, 2018 at 11:47:17AM +0100, Clément Péron wrote: > >

Re: [PATCH 2/2] pwm: bcm-kona: apply pwm settings on enable

On Thu, Nov 8, 2018 at 2:59 AM Uwe Kleine-König wrote: > > Hello, > > adding Tim Kryger as the initial author of the bcm-kona driver to Cc:. > Maybe he can shed some light to the questions below? > > On Thu, Nov 08, 2018 at 11:47:17AM +0100, Clément Péron wrote: > >

Re: [linux-sunxi] Designware UART bug

On Wed, May 3, 2017 at 8:40 AM, Olliver Schinagl wrote: > Hey Tim, > > Ok, so as far as I understand (from the datasheet) the intended way to do > this would be to check for the BUSY IRQ & USR[0] IRQ and if it is busy, > (re-write) the LCR. We no longer do this because it did

Re: [linux-sunxi] Designware UART bug

On Wed, May 3, 2017 at 8:40 AM, Olliver Schinagl wrote: > Hey Tim, > > Ok, so as far as I understand (from the datasheet) the intended way to do > this would be to check for the BUSY IRQ & USR[0] IRQ and if it is busy, > (re-write) the LCR. We no longer do this because it did not work due to the

Re: [linux-sunxi] Designware UART bug

On Wed, May 3, 2017 at 4:26 AM, Olliver Schinagl wrote: > Hey Chen-Yu > > On 03-05-17 12:40, Chen-Yu Tsai wrote: >> >> On Wed, May 3, 2017 at 6:17 PM, Olliver Schinagl >> wrote: >>> >>> Hey Jamie, >>> >>> Several years ago you wrote the glue-code [0] for

Re: [linux-sunxi] Designware UART bug

On Wed, May 3, 2017 at 4:26 AM, Olliver Schinagl wrote: > Hey Chen-Yu > > On 03-05-17 12:40, Chen-Yu Tsai wrote: >> >> On Wed, May 3, 2017 at 6:17 PM, Olliver Schinagl >> wrote: >>> >>> Hey Jamie, >>> >>> Several years ago you wrote the glue-code [0] for the DW 8250 IP. Over >>> the >>> years

Re: [PATCH v0 2/4] i2c: bcm-kona: Use complete() instead of complete_all()

e() instead of complete_all(). > > The usage pattern of the completion is: > > bcm_kona_send_i2c_cmd() > reinit_completion() > ... > bcm_kona_i2c_send_cmd_to_ctrl() > ... > wait_for_completion_timeout() > > Signed-off-by: Daniel Wagner <daniel.wag.

Re: [PATCH v0 2/4] i2c: bcm-kona: Use complete() instead of complete_all()

ern of the completion is: > > bcm_kona_send_i2c_cmd() > reinit_completion() > ... > bcm_kona_i2c_send_cmd_to_ctrl() > ... > wait_for_completion_timeout() > > Signed-off-by: Daniel Wagner Reviewed-by: Tim Kryger > --- > drivers/i2c/busses/i2c-bcm-kona.

Re: [PATCH v8 1/5] drivers: pwm: core: Add pwmchip_add_inversed

On Fri, Jun 12, 2015 at 2:45 AM, Thierry Reding wrote: > On Tue, May 26, 2015 at 01:08:16PM -0700, Jonathan Richardson wrote: >> From: Tim Kryger >> >> Add a new function to register a PWM chip with channels that have their >> initial polarity as inversed. This bene

Re: [PATCH v8 1/5] drivers: pwm: core: Add pwmchip_add_inversed

On Fri, Jun 12, 2015 at 2:45 AM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, May 26, 2015 at 01:08:16PM -0700, Jonathan Richardson wrote: From: Tim Kryger tim.kry...@gmail.com Add a new function to register a PWM chip with channels that have their initial polarity as inversed

Re: [PATCH v8 4/5] pwm: kona: Add debug info to config function

On Tue, May 26, 2015 at 1:08 PM, Jonathan Richardson wrote: > Adds debugging info to config function where duty cycle and period > are calculated and verified. > > Signed-off-by: Jonathan Richardson > --- > drivers/pwm/pwm-bcm-kona.c | 25 +++-- > 1 file changed, 23

Re: [PATCH v8 3/5] pwm: kona: Fix incorrect config, disable, and polarity procedures

400ns. This corrects an issue where occasionally a requested change was not properly reflected in the PWM output. Otherwise, this patch looks reasonable so Reviewed-by: Tim Kryger > > Reviewed-by: Arun Ramamurthy > Reviewed-by: Scott Branden > Tested-by: Scott Branden >

Re: [PATCH v8 4/5] pwm: kona: Add debug info to config function

On Tue, May 26, 2015 at 1:08 PM, Jonathan Richardson jonat...@broadcom.com wrote: Adds debugging info to config function where duty cycle and period are calculated and verified. Signed-off-by: Jonathan Richardson jonat...@broadcom.com --- drivers/pwm/pwm-bcm-kona.c | 25

Re: [PATCH v8 3/5] pwm: kona: Fix incorrect config, disable, and polarity procedures

. This corrects an issue where occasionally a requested change was not properly reflected in the PWM output. Otherwise, this patch looks reasonable so Reviewed-by: Tim Kryger tim.kry...@gmail.com Reviewed-by: Arun Ramamurthy arunr...@broadcom.com Reviewed-by: Scott Branden sbran...@broadcom.com

Re: [PATCH v7 3/5] pwm: kona: Fix incorrect config, disable, and polarity procedures

On Thu, May 21, 2015 at 3:50 PM, Jonathan Richardson wrote: > If this is correct - polarity changes affect the output signal > immediately, then I can change our driver. Could you confirm first this > is what we want? Yes. This seems best. Please do. -Tim -- To unsubscribe from this list:

Re: [PATCH v7 3/5] pwm: kona: Fix incorrect config, disable, and polarity procedures

On Thu, May 21, 2015 at 3:50 PM, Jonathan Richardson jonat...@broadcom.com wrote: If this is correct - polarity changes affect the output signal immediately, then I can change our driver. Could you confirm first this is what we want? Yes. This seems best. Please do. -Tim -- To unsubscribe

Re: [PATCH v7 3/5] pwm: kona: Fix incorrect config, disable, and polarity procedures

On Tue, May 12, 2015 at 4:28 PM, Jonathan Richardson wrote: > The polarity procedure no longer applies the settings to change the > output signal because it can't be called when the pwm is enabled anyway. > The polarity is only updated in the control register. The correct > polarity will be

Re: [PATCH v7 3/5] pwm: kona: Fix incorrect config, disable, and polarity procedures

On Tue, May 12, 2015 at 4:28 PM, Jonathan Richardson jonat...@broadcom.com wrote: The polarity procedure no longer applies the settings to change the output signal because it can't be called when the pwm is enabled anyway. The polarity is only updated in the control register. The correct

Re: [PATCH v6 3/4] pwm: kona: Fix incorrect config, disable, and polarity procedures

On Fri, Apr 10, 2015 at 11:58 AM, Jonathan Richardson wrote: > The polarity procedure no longer applies the settings to change the > output signal because it can't be called when the pwm is enabled anyway. > The polarity is only updated in the control register. The correct > polarity will be

Re: [PATCH v6 3/4] pwm: kona: Fix incorrect config, disable, and polarity procedures

On Fri, Apr 10, 2015 at 11:58 AM, Jonathan Richardson jonat...@broadcom.com wrote: The polarity procedure no longer applies the settings to change the output signal because it can't be called when the pwm is enabled anyway. The polarity is only updated in the control register. The correct

Re: [RFC] With 8250 Designware UART, if writes to the LCR failed the kernel will hung up

On Mon, Mar 9, 2015 at 8:05 AM, Alan Cox wrote: > Ah no - I meant what is their official software workaround for existing > parts with the bug ? Presumably they have an errata document that > discusses this and the correct methods they recommend to avoid the > hang ? As far as I know, the only

Re: [RFC] With 8250 Designware UART, if writes to the LCR failed the kernel will hung up

On Mon, Mar 9, 2015 at 6:32 AM, Alan Cox wrote: >> Maybe the next release of the board we will upgrade the serial block to the >> new version. >> but the issue is that how we circumvent this problem in kernel? > > What is the official vendor workaround ? They introduced a UART_16550_COMPATIBLE

Re: [RFC] With 8250 Designware UART, if writes to the LCR failed the kernel will hung up

On Mon, Mar 9, 2015 at 6:32 AM, Alan Cox a...@linux.intel.com wrote: Maybe the next release of the board we will upgrade the serial block to the new version. but the issue is that how we circumvent this problem in kernel? What is the official vendor workaround ? They introduced a

Re: [RFC] With 8250 Designware UART, if writes to the LCR failed the kernel will hung up

On Mon, Mar 9, 2015 at 8:05 AM, Alan Cox a...@linux.intel.com wrote: Ah no - I meant what is their official software workaround for existing parts with the bug ? Presumably they have an errata document that discusses this and the correct methods they recommend to avoid the hang ? As far as I

Re: [RFC] With 8250 Designware UART, if writes to the LCR failed the kernel will hung up

You only hit the silicon bug if you bombard the uart with characters and simultaneously request a baud rate or framing change. I'm not sure why you would do either to the uart console. Is it possible your host machine is doing something weird? If you have the leverage, remind the SoC vendor to

Re: [RFC] With 8250 Designware UART, if writes to the LCR failed the kernel will hung up

You only hit the silicon bug if you bombard the uart with characters and simultaneously request a baud rate or framing change. I'm not sure why you would do either to the uart console. Is it possible your host machine is doing something weird? If you have the leverage, remind the SoC vendor to

[PATCH] mmc: sdhci: Set SDHCI_POWER_ON with external vmmc

and Nvidia boards caused by 5222161 mmc: sdhci: Improve external VDD regulator support. Signed-off-by: Tim Kryger Tested-by: Bjorn Andersson --- drivers/mmc/host/sdhci.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index ada1a3e..59a328a

Re: Possible regression with commit 52221610d

On Sun, Dec 21, 2014 at 7:01 PM, Tim Kryger wrote: > On Wed, Dec 17, 2014 at 11:57 AM, Bjorn Andersson wrote: > >> I'm somewhat puzzled to what benefit 52221610d brings after bringing >> back the write of BIT(0). Is it just that we don't hit the BUG() on >&g

Re: Possible regression with commit 52221610d

On Mon, Jan 12, 2015 at 2:31 AM, Ulf Hansson wrote: > On 5 January 2015 at 20:52, Bjorn Andersson wrote: >> On Sun, Dec 21, 2014 at 7:01 PM, Tim Kryger wrote: >>> On Wed, Dec 17, 2014 at 11:57 AM, Bjorn Andersson wrote: >> [..] >>>> Non-the-less, feel fre

Re: Possible regression with commit 52221610d

On Mon, Jan 5, 2015 at 11:52 AM, Bjorn Andersson wrote: > On Sun, Dec 21, 2014 at 7:01 PM, Tim Kryger wrote: >> On Wed, Dec 17, 2014 at 11:57 AM, Bjorn Andersson wrote: > [..] >>> Non-the-less, feel free to propose a patch and I will give it a test. >> >> Le

Re: Possible regression with commit 52221610d

On Sun, Dec 21, 2014 at 7:01 PM, Tim Kryger tim.kry...@gmail.com wrote: On Wed, Dec 17, 2014 at 11:57 AM, Bjorn Andersson bj...@kryo.se wrote: I'm somewhat puzzled to what benefit 52221610d brings after bringing back the write of BIT(0). Is it just that we don't hit the BUG() on non-standard

[PATCH] mmc: sdhci: Set SDHCI_POWER_ON with external vmmc

and Nvidia boards caused by 5222161 mmc: sdhci: Improve external VDD regulator support. Signed-off-by: Tim Kryger tim.kry...@gmail.com Tested-by: Bjorn Andersson bjorn.anders...@sonymobile.com --- drivers/mmc/host/sdhci.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/mmc/host/sdhci.c

Re: Possible regression with commit 52221610d

On Mon, Jan 5, 2015 at 11:52 AM, Bjorn Andersson bj...@kryo.se wrote: On Sun, Dec 21, 2014 at 7:01 PM, Tim Kryger tim.kry...@gmail.com wrote: On Wed, Dec 17, 2014 at 11:57 AM, Bjorn Andersson bj...@kryo.se wrote: [..] Non-the-less, feel free to propose a patch and I will give it a test. Lets

Re: Possible regression with commit 52221610d

On Mon, Jan 12, 2015 at 2:31 AM, Ulf Hansson ulf.hans...@linaro.org wrote: On 5 January 2015 at 20:52, Bjorn Andersson bj...@kryo.se wrote: On Sun, Dec 21, 2014 at 7:01 PM, Tim Kryger tim.kry...@gmail.com wrote: On Wed, Dec 17, 2014 at 11:57 AM, Bjorn Andersson bj...@kryo.se wrote: [..] Non

Re: [PATCH v4 2/3] pwm: kona: Remove setting default smooth type and polarity for all channels

On Sun, Jan 4, 2015 at 5:12 PM, Tim Kryger wrote: > On Tue, Dec 30, 2014 at 2:43 PM, Jonathan Richardson > wrote: >> Setting the default polarity in probe to normal for all channels caused >> the speaker pwm channel to click. The polarity does need to be set to >> norma

[PATCH 2/2] drivers: pwm: bcm-kona: Dont set polarity in probe

Signed-off-by: Scott Branden Signed-off-by: Tim Kryger --- This is based on Arun's patch (originally posted by Scott) https://lkml.org/lkml/2014/11/25/1019 I modified it to use the pwmchip_add_inversed function so the polarity could be safely left at the power on default and updated the commit

[PATCH 0/2] Allow registration of default inversed polarity PWMs

This series alters the PWM core to allow the registration of controllers that begin with inversed polarity output. It also modifies the Broadcom Kona driver to take advantage of this new call. Arun Ramamurthy (1): drivers: pwm: bcm-kona: Dont set polarity in probe Tim Kryger (1): drivers

[PATCH 1/2] drivers: pwm: core: Add pwmchip_add_inversed

Add a new function to register a PWM chip with channels that have their initial polarity as inversed. This benefits drivers of controllers that by default operate with inversed polarity by removing the need to modify the polarity during initialization. Signed-off-by: Tim Kryger --- drivers/pwm

Re: [PATCH v4 2/3] pwm: kona: Remove setting default smooth type and polarity for all channels

On Tue, Dec 30, 2014 at 2:43 PM, Jonathan Richardson wrote: > Setting the default polarity in probe to normal for all channels caused > the speaker pwm channel to click. The polarity does need to be set to > normal because the hw default is inversed whereas the pwm framework > defaults to normal.

[PATCH 2/2] drivers: pwm: bcm-kona: Dont set polarity in probe

arunr...@broadcom.com Reviewed-by: Ray Jui r...@broadcom.com Signed-off-by: Scott Branden sbran...@broadcom.com Signed-off-by: Tim Kryger tim.kry...@gmail.com --- This is based on Arun's patch (originally posted by Scott) https://lkml.org/lkml/2014/11/25/1019 I modified it to use

[PATCH 0/2] Allow registration of default inversed polarity PWMs

This series alters the PWM core to allow the registration of controllers that begin with inversed polarity output. It also modifies the Broadcom Kona driver to take advantage of this new call. Arun Ramamurthy (1): drivers: pwm: bcm-kona: Dont set polarity in probe Tim Kryger (1): drivers

[PATCH 1/2] drivers: pwm: core: Add pwmchip_add_inversed

Add a new function to register a PWM chip with channels that have their initial polarity as inversed. This benefits drivers of controllers that by default operate with inversed polarity by removing the need to modify the polarity during initialization. Signed-off-by: Tim Kryger tim.kry

Re: [PATCH v4 2/3] pwm: kona: Remove setting default smooth type and polarity for all channels

On Tue, Dec 30, 2014 at 2:43 PM, Jonathan Richardson jonat...@broadcom.com wrote: Setting the default polarity in probe to normal for all channels caused the speaker pwm channel to click. The polarity does need to be set to normal because the hw default is inversed whereas the pwm framework

Re: [PATCH v4 2/3] pwm: kona: Remove setting default smooth type and polarity for all channels

On Sun, Jan 4, 2015 at 5:12 PM, Tim Kryger tim.kry...@gmail.com wrote: On Tue, Dec 30, 2014 at 2:43 PM, Jonathan Richardson jonat...@broadcom.com wrote: Setting the default polarity in probe to normal for all channels caused the speaker pwm channel to click. The polarity does need to be set

Re: Possible regression with commit 52221610d

On Wed, Dec 17, 2014 at 11:57 AM, Bjorn Andersson wrote: > I'm somewhat puzzled to what benefit 52221610d brings after bringing > back the write of BIT(0). Is it just that we don't hit the BUG() on > non-standard voltages? It is to allow the use of external regulators that are capable of

Re: Possible regression with commit 52221610d

On Wed, Dec 17, 2014 at 11:57 AM, Bjorn Andersson bj...@kryo.se wrote: I'm somewhat puzzled to what benefit 52221610d brings after bringing back the write of BIT(0). Is it just that we don't hit the BUG() on non-standard voltages? It is to allow the use of external regulators that are capable

Re: [PATCH v3 1/2] pwm: kona: Fix incorrect enable, config, and disable procedures

On Wed, Dec 17, 2014 at 10:46 AM, Jonathan Richardson wrote: > The config procedure doesn't follow the spec which periodically results > in failing to enable the output signal. This happens one in ten or > twenty attempts. Following the spec and adding a 400ns delay in the >

Re: [PATCH v3 1/2] pwm: kona: Fix incorrect enable, config, and disable procedures

On Wed, Dec 17, 2014 at 10:46 AM, Jonathan Richardson jonat...@broadcom.com wrote: The config procedure doesn't follow the spec which periodically results in failing to enable the output signal. This happens one in ten or twenty attempts. Following the spec and adding a 400ns delay

Re: Possible regression with commit 52221610d

d to bit zero of that same register. The driver should be updated to configure bit zero appropriately even when an external regulator is used. If you like, I can propose a patch or if you have one ready, I will be happy to review yours. Thanks, Tim Kryger -- To unsubscribe from this lis

Re: Possible regression with commit 52221610d

be updated to configure bit zero appropriately even when an external regulator is used. If you like, I can propose a patch or if you have one ready, I will be happy to review yours. Thanks, Tim Kryger -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message

Re: [PATCH v2 1/2] pwm: kona: Fix incorrect enable, config, and disable procedures

t are both low, the output is constant high. If you look at the PWM output on a scope you will see it go high for 400 ns during your disable even if the duty prior to the disable was zero. How are you testing your proposed changes? Thanks, Tim Kryger -- To unsubscribe from this list: send the l

Re: Possible regression with commit 52221610d

On Sat, Dec 13, 2014 at 11:22 PM, Bjorn Andersson wrote: > On Tue, Nov 4, 2014 at 7:31 AM, Tim Kryger wrote: >> On Tue, Nov 4, 2014 at 1:00 AM, Alexandre Courbot >> wrote: >>> Hi Tim, thanks for your reply! >>> >>> On 11/04/2014 02:28 PM, Tim Kryger wr

Re: Possible regression with commit 52221610d

On Sat, Dec 13, 2014 at 11:22 PM, Bjorn Andersson bj...@kryo.se wrote: On Tue, Nov 4, 2014 at 7:31 AM, Tim Kryger tim.kry...@gmail.com wrote: On Tue, Nov 4, 2014 at 1:00 AM, Alexandre Courbot acour...@nvidia.com wrote: Hi Tim, thanks for your reply! On 11/04/2014 02:28 PM, Tim Kryger wrote

Re: [PATCH v2 1/2] pwm: kona: Fix incorrect enable, config, and disable procedures

to the disable was zero. How are you testing your proposed changes? Thanks, Tim Kryger -- 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

Re: [PATCH v2 1/4] pwm: kona: Remove setting default smooth type and polarity for all channels

sition. So it's important to follow the spec > here. We don't want non-smooth transitions. Please provide your rationale for requiring smooth transitions. Thanks, Tim Kryger -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to ma

Re: [PATCH 2/4] clk: iproc: add initial common clock support

On Thu, Dec 4, 2014 at 1:43 PM, Ray Jui wrote: > This adds basic and generic support for various iProc PLLs and clocks > including the ARMPLL, GENPLL, LCPLL, MIPIPLL, and ASIU clocks. > > SoCs under the iProc architecture can define their specific register > offsets and clock parameters for their

Re: [PATCH 2/4] clk: iproc: add initial common clock support

On Thu, Dec 4, 2014 at 1:43 PM, Ray Jui r...@broadcom.com wrote: This adds basic and generic support for various iProc PLLs and clocks including the ARMPLL, GENPLL, LCPLL, MIPIPLL, and ASIU clocks. SoCs under the iProc architecture can define their specific register offsets and clock

Re: [PATCH v2 1/4] pwm: kona: Remove setting default smooth type and polarity for all channels

provide your rationale for requiring smooth transitions. Thanks, Tim Kryger -- 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

Re: [PATCH v2 3/4] pwm: kona: Fix enable, disable and config procedures

On Mon, Dec 1, 2014 at 11:37 AM, Arun Ramamurthy wrote: > > > On 14-11-28 06:30 PM, Tim Kryger wrote: >> >> On Fri, Nov 28, 2014 at 3:49 PM, Arun Ramamurthy >> wrote: >>> >>> >>> >>> On 14-11-25 11:29 PM, Tim Kryger wrote:

Re: [PATCH v2 3/4] pwm: kona: Fix enable, disable and config procedures

On Mon, Dec 1, 2014 at 11:37 AM, Arun Ramamurthy arun.ramamur...@broadcom.com wrote: On 14-11-28 06:30 PM, Tim Kryger wrote: On Fri, Nov 28, 2014 at 3:49 PM, Arun Ramamurthy arun.ramamur...@broadcom.com wrote: On 14-11-25 11:29 PM, Tim Kryger wrote: On Tue, Nov 25, 2014 at 11:40 AM

Re: [PATCH v2 1/4] pwm: kona: Remove setting default smooth type and polarity for all channels

On Fri, Nov 28, 2014 at 5:19 PM, Arun Ramamurthy wrote: > > > On 14-11-28 05:08 PM, Tim Kryger wrote: >> >> On Fri, Nov 28, 2014 at 3:47 PM, Arun Ramamurthy >> wrote: >>> >>> >>> >>> On 14-11-25 09:51 PM, Tim Kryger wrote:

Re: [PATCH v2 3/4] pwm: kona: Fix enable, disable and config procedures

On Fri, Nov 28, 2014 at 3:49 PM, Arun Ramamurthy wrote: > > > On 14-11-25 11:29 PM, Tim Kryger wrote: >> >> On Tue, Nov 25, 2014 at 11:40 AM, Scott Branden >> wrote: >>> >>> From: Arun Ramamurthy >>> >>> - Added helper functions to

Re: [PATCH v2 2/4] pwm: kona: Fix incorrect enable after channel polarity change

On Fri, Nov 28, 2014 at 3:48 PM, Arun Ramamurthy wrote: > > > On 14-11-25 10:22 PM, Tim Kryger wrote: >> >> On Tue, Nov 25, 2014 at 11:40 AM, Scott Branden >> wrote: >>> >>> From: Arun Ramamurthy >>> >>> The pwm core code

Re: [PATCH v2 1/4] pwm: kona: Remove setting default smooth type and polarity for all channels

On Fri, Nov 28, 2014 at 3:47 PM, Arun Ramamurthy wrote: > > > On 14-11-25 09:51 PM, Tim Kryger wrote: >> >> On Tue, Nov 25, 2014 at 11:40 AM, Scott Branden >> wrote: >>> >>> From: Arun Ramamurthy >>> >>> The probe routine unnec

Re: [PATCH v2 1/4] pwm: kona: Remove setting default smooth type and polarity for all channels

On Fri, Nov 28, 2014 at 3:47 PM, Arun Ramamurthy arun.ramamur...@broadcom.com wrote: On 14-11-25 09:51 PM, Tim Kryger wrote: On Tue, Nov 25, 2014 at 11:40 AM, Scott Branden sbran...@broadcom.com wrote: From: Arun Ramamurthy arunr...@broadcom.com The probe routine unnecessarily sets

Re: [PATCH v2 2/4] pwm: kona: Fix incorrect enable after channel polarity change

On Fri, Nov 28, 2014 at 3:48 PM, Arun Ramamurthy arun.ramamur...@broadcom.com wrote: On 14-11-25 10:22 PM, Tim Kryger wrote: On Tue, Nov 25, 2014 at 11:40 AM, Scott Branden sbran...@broadcom.com wrote: From: Arun Ramamurthy arunr...@broadcom.com The pwm core code requires a separate call

Re: [PATCH v2 3/4] pwm: kona: Fix enable, disable and config procedures

On Fri, Nov 28, 2014 at 3:49 PM, Arun Ramamurthy arun.ramamur...@broadcom.com wrote: On 14-11-25 11:29 PM, Tim Kryger wrote: On Tue, Nov 25, 2014 at 11:40 AM, Scott Branden sbran...@broadcom.com wrote: From: Arun Ramamurthy arunr...@broadcom.com - Added helper functions to set and clear

Re: [PATCH v2 1/4] pwm: kona: Remove setting default smooth type and polarity for all channels

On Fri, Nov 28, 2014 at 5:19 PM, Arun Ramamurthy arun.ramamur...@broadcom.com wrote: On 14-11-28 05:08 PM, Tim Kryger wrote: On Fri, Nov 28, 2014 at 3:47 PM, Arun Ramamurthy arun.ramamur...@broadcom.com wrote: On 14-11-25 09:51 PM, Tim Kryger wrote: On Tue, Nov 25, 2014 at 11:40 AM

Re: [PATCH v2 3/4] pwm: kona: Fix enable, disable and config procedures

On Tue, Nov 25, 2014 at 11:40 AM, Scott Branden wrote: > From: Arun Ramamurthy > > - Added helper functions to set and clear smooth and trigger bits > - Added 400ns delays when clearing and setting trigger bit as requied > by spec > - Added helper function to write prescale and other settings

Re: [PATCH v2 2/4] pwm: kona: Fix incorrect enable after channel polarity change

On Tue, Nov 25, 2014 at 11:40 AM, Scott Branden wrote: > From: Arun Ramamurthy > > The pwm core code requires a separate call for enabling the channel > and hence the driver does not need to set pwm_trigger after a > polarity change The framework does restrict when polarity changes can occur

Re: [PATCH v2 1/4] pwm: kona: Remove setting default smooth type and polarity for all channels

On Tue, Nov 25, 2014 at 11:40 AM, Scott Branden wrote: > From: Arun Ramamurthy > > The probe routine unnecessarily sets the smooth type and polarity for > all channels. This causes the channel for the speaker to click at the same > time the backlight turns on. The smooth type and polarity should

Re: [PATCH v2 1/4] pwm: kona: Remove setting default smooth type and polarity for all channels

On Tue, Nov 25, 2014 at 11:40 AM, Scott Branden sbran...@broadcom.com wrote: From: Arun Ramamurthy arunr...@broadcom.com The probe routine unnecessarily sets the smooth type and polarity for all channels. This causes the channel for the speaker to click at the same time the backlight turns

Re: [PATCH v2 2/4] pwm: kona: Fix incorrect enable after channel polarity change

On Tue, Nov 25, 2014 at 11:40 AM, Scott Branden sbran...@broadcom.com wrote: From: Arun Ramamurthy arunr...@broadcom.com The pwm core code requires a separate call for enabling the channel and hence the driver does not need to set pwm_trigger after a polarity change The framework does

Re: [PATCH v2 3/4] pwm: kona: Fix enable, disable and config procedures

On Tue, Nov 25, 2014 at 11:40 AM, Scott Branden sbran...@broadcom.com wrote: From: Arun Ramamurthy arunr...@broadcom.com - Added helper functions to set and clear smooth and trigger bits - Added 400ns delays when clearing and setting trigger bit as requied by spec - Added helper function

Re: Possible regression with commit 52221610d

On Wed, Nov 5, 2014 at 12:10 AM, Alexandre Courbot wrote: > On 11/05/2014 12:31 AM, Tim Kryger wrote: >> >> On Tue, Nov 4, 2014 at 1:00 AM, Alexandre Courbot >> wrote: >>> >>> Hi Tim, thanks for your reply! >>> >>> On 11/04/2014 02:28 PM,

Re: Possible regression with commit 52221610d

On Wed, Nov 5, 2014 at 12:10 AM, Alexandre Courbot acour...@nvidia.com wrote: On 11/05/2014 12:31 AM, Tim Kryger wrote: On Tue, Nov 4, 2014 at 1:00 AM, Alexandre Courbot acour...@nvidia.com wrote: Hi Tim, thanks for your reply! On 11/04/2014 02:28 PM, Tim Kryger wrote: On Mon, Nov 3

Re: Possible regression with commit 52221610d

On Tue, Nov 4, 2014 at 1:00 AM, Alexandre Courbot wrote: > Hi Tim, thanks for your reply! > > On 11/04/2014 02:28 PM, Tim Kryger wrote: >> >> On Mon, Nov 3, 2014 at 7:05 PM, Alexandre Courbot >> wrote: >>> >>> Hi guys, >>> >>>

Re: Possible regression with commit 52221610d

On Tue, Nov 4, 2014 at 1:00 AM, Alexandre Courbot acour...@nvidia.com wrote: Hi Tim, thanks for your reply! On 11/04/2014 02:28 PM, Tim Kryger wrote: On Mon, Nov 3, 2014 at 7:05 PM, Alexandre Courbot acour...@nvidia.com wrote: Hi guys, On the NVIDIA shield (tegra114-roth) platform, I

Re: Possible regression with commit 52221610d

egulator_set_ocr(mmc, mmc->supply.vmmc, vdd); > + spin_lock_irq(>lock); > + } > } > > Does this look like the right approach? If not, would you have any > suggestion as to how to solve this problem? The patch you proposed would break Exynos4210 so I

Re: Possible regression with commit 52221610d

this problem? The patch you proposed would break Exynos4210 so I don't think it is appropriate. Do you understand why this code block is executed on your hardware? I wouldn't expect it. Can you provide the relevant parts of the log before the problem occurs? Thanks, Tim Kryger -- To unsubscribe from

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

On Fri, Aug 15, 2014 at 3:29 PM, Mark Brown wrote: > On Fri, Aug 15, 2014 at 07:19:41AM -0700, Tim Kryger wrote: > >> That is a little different from my suggestion where the constraints >> check is skipped when the regulator output is fixed. It effectively >> does thi

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

On Fri, Aug 15, 2014 at 3:29 PM, Mark Brown broo...@kernel.org wrote: On Fri, Aug 15, 2014 at 07:19:41AM -0700, Tim Kryger wrote: That is a little different from my suggestion where the constraints check is skipped when the regulator output is fixed. It effectively does this now when

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

On Fri, Aug 15, 2014 at 12:48 AM, Javier Martinez Canillas wrote: > Hello Tim, > > On 08/15/2014 07:36 AM, Tim Kryger wrote: >> On Thu, Aug 14, 2014 at 8:19 AM, Mark Brown wrote: >> >>> Right, there's two things going on here. One is that as you describe we >&g

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

On Fri, Aug 15, 2014 at 12:48 AM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: Hello Tim, On 08/15/2014 07:36 AM, Tim Kryger wrote: On Thu, Aug 14, 2014 at 8:19 AM, Mark Brown broo...@kernel.org wrote: Right, there's two things going on here. One is that as you describe

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

be the ones to handle this subtlety. Thanks, Tim Kryger -- 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/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

On Thu, Aug 14, 2014 at 5:39 AM, Javier Martinez Canillas wrote: > The operation conditions register (OCR) stores the voltage > profile of the card, however the list of possible voltages > is restricted by the voltage range supported by the supply > used as VCC/VDD. So in

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

On Thu, Aug 14, 2014 at 5:39 AM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: The operation conditions register (OCR) stores the voltage profile of the card, however the list of possible voltages is restricted by the voltage range supported by the supply used as VCC/VDD. So

Re: [PATCH 1/1] mmc: core: Use regulator_get_voltage() if OCR mask is empty.

to handle this subtlety. Thanks, Tim Kryger -- 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 v2] mmc: core: Remove fixed voltage regulator logic

There is no need for regulator consumers to include special logic for fixed voltage regulators as they support regulator_set_voltage() just like their non-fixed regulator counterparts. Signed-off-by: Tim Kryger --- Changes in v2: - Remove query of the current voltage, just set the desired

[PATCH v2] mmc: core: Remove fixed voltage regulator logic

There is no need for regulator consumers to include special logic for fixed voltage regulators as they support regulator_set_voltage() just like their non-fixed regulator counterparts. Signed-off-by: Tim Kryger tim.kry...@gmail.com --- Changes in v2: - Remove query of the current voltage, just

[RESEND PATCH] mmc: core: Remove fixed voltage regulator logic

There is no need for regulator consumers to include special logic for fixed voltage regulators as they support regulator_set_voltage() just like their non-fixed regulator counterparts. Signed-off-by: Tim Kryger --- Since this eliminates logic that was concealing a bug in how the SDHCI driver

[RESEND PATCH] mmc: core: Remove fixed voltage regulator logic

There is no need for regulator consumers to include special logic for fixed voltage regulators as they support regulator_set_voltage() just like their non-fixed regulator counterparts. Signed-off-by: Tim Kryger tim.kry...@gmail.com --- Since this eliminates logic that was concealing a bug in how

[PATCH] mmc: core: Remove fixed voltage regulator logic

There is no need for regulator consumers to include special logic for fixed voltage regulators as they support regulator_set_voltage() just like their non-fixed regulator counterparts. Signed-off-by: Tim Kryger --- Since this eliminates logic that was concealing a bug in how the SDHCI driver

[PATCH] mmc: core: Remove fixed voltage regulator logic

There is no need for regulator consumers to include special logic for fixed voltage regulators as they support regulator_set_voltage() just like their non-fixed regulator counterparts. Signed-off-by: Tim Kryger tim.kry...@gmail.com --- Since this eliminates logic that was concealing a bug in how

[PATCH] mmc: sdhci: Improve external VDD regulator support

-by: Tim Kryger Tested-by: Sachin Kamat --- This change corrects a regression observed on Exynos platforms that was triggered by "mmc: sdhci: Use mmc core regulator infrastucture" https://www.mail-archive.com/linux-mmc@vger.kernel.org/msg27101.html drivers/mmc/host/sdhci.c | 16 +

[PATCH] mmc: sdhci: Improve external VDD regulator support

-by: Tim Kryger tim.kry...@gmail.com Tested-by: Sachin Kamat spk.li...@gmail.com --- This change corrects a regression observed on Exynos platforms that was triggered by mmc: sdhci: Use mmc core regulator infrastucture https://www.mail-archive.com/linux-mmc@vger.kernel.org/msg27101.html drivers/mmc

Re: [PATCH 1/3] regulator: bcm590xx: remove unnecessary OOM messages

On Mon, Jun 2, 2014 at 5:50 AM, Mark Brown wrote: > On Mon, Jun 02, 2014 at 12:12:20AM -0700, Tim Kryger wrote: > >> The probe method of this driver, on the other hand, performs several >> allocations and the error messages you intend to remove conveniently >> pinpoint

Re: [PATCH 1/3] regulator: bcm590xx: remove unnecessary OOM messages

On Mon, Jun 2, 2014 at 5:50 AM, Mark Brown broo...@kernel.org wrote: On Mon, Jun 02, 2014 at 12:12:20AM -0700, Tim Kryger wrote: The probe method of this driver, on the other hand, performs several allocations and the error messages you intend to remove conveniently pinpoint which one failed

Re: [PATCH 1/3] regulator: bcm590xx: remove unnecessary OOM messages

is patch series, the probe methods only include a single dynamic memory allocation. As such, the stack trace provided by the generic memory code is sufficient to quickly identify where the failure occurred. The probe method of this driver, on the other hand, performs several allocations and the e

Re: [PATCH 1/3] regulator: bcm590xx: remove unnecessary OOM messages

several allocations and the error messages you intend to remove conveniently pinpoint which one failed. While the offsets in the trace could be used to derive the same information, I am skeptical that is enough to justify removing the messages. Thanks, Tim Kryger -- To unsubscribe from this list

  1   2   3   4   5   >