There is no real benefit from doing so, hence let's drop that rate setting
for consistency.
Reviewed-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra-devfreq.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/
The frequency value potentially could change in-between. It doesn't
cause any real problem at all right now, but that could change in the
future. Hence let's avoid the inconsistency.
Reviewed-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra-devfreq.c | 6
The driver's compilation doesn't have any specific dependencies, hence
the COMPILE_TEST option can be supported in Kconfig.
Reviewed-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drive
The clk_set_min_rate() could fail and in this case clk_set_rate() sets
rate to 0, which may drop EMC rate to minimum and make machine very
difficult to use.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra-devfreq.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions
The devfreq driver can be used on Tegra30 without any code change and
it works perfectly fine, the default Tegra124 parameters are good enough
for Tegra30.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/Kconfig | 4 ++--
drivers/devfreq/tegra-devfreq.c | 1 +
2 files changed, 3
There is no need to insert memory barrier on each readl/writel
invocation, hence use the relaxed versions.
Reviewed-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra-devfreq.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/devfreq
Reset hardware, disable ACTMON clock, release OPP's and handle all
possible error cases correctly, maintaining the correct tear down
order. Also use devm_platform_ioremap_resource() which is now available
in the kernel.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra-devfreq.c
ling works properly now.
Cc: # 4.14+
Tested-by: Steev Klimaszewski
Reviewed-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra-devfreq.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra
In order to reflect that driver serves NVIDIA Tegra30 and later SoC
generations, let's rename the driver's source file to "tegra30-devfreq.c".
This will make driver files to look more consistent after addition of a
driver for Tegra20.
Signed-off-by: Dmitry Osipenko
---
driv
freq about
the required memory frequency. This change also cleans up code a tad
by moving hardware-configuration code into a single location.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra-devfreq.c | 98 ++---
1 file changed, 40 insertions(+), 58 deletion
The write memory barrier isn't needed because the BUS buffer is flushed
by read after write that happens after the removed wmb(), we will also
use readl() instead of the relaxed version to ensure that read is indeed
completed.
Reviewed-by: Chanwoo Choi
Signed-off-by: Dmitry Osi
terrupt is indeed being disabled.
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra-devfreq.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
index b65313fe3c2e..ce1eb97a2090 10
There is no real need in the primary interrupt handler, hence move
everything to the secondary (threaded) handler. In a result locking
is consistent now and there are no potential races with the interrupt
handler because it is protected with the devfreq's mutex.
Signed-off-by: Dmitry Osi
iver's
code got more clean up.
The Tegra20 driver-addition patch is now a part of this series, it has
no changes since v1.
https://patchwork.ozlabs.org/project/linux-tegra/list/?series=102823
Dmitry Osipenko (16):
PM / devfreq: tegra: Fix kHz to Hz conversion
PM / devfre
The ACTMON's governor supports only the Tegra's devfreq device and there
is no need to use any other governor, hence let's mark Tegra governor as
immutable to permanently stick it with Tegra's devfreq device.
Reviewed-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
---
dri
There is no need to register the ACTMON's governor separately from
the driver, hence let's move the registration into the driver's probe
function for consistency and to make code cleaner a tad.
Reviewed-by: Chanwoo Choi
Signed-off-by: Dmitry Osipenko
---
drivers/devfreq/tegra
Add devfreq driver for NVIDIA Tegra20 SoC's. The driver periodically
reads out Memory Controller counters and adjusts memory frequency based
on the memory clients activity.
Signed-off-by: Dmitry Osipenko
---
MAINTAINERS | 8 ++
drivers/devfreq/Kconfig
ks
Hello Ben,
Thank you very much for keeping it up. I have couple comments, please see them
below.
> Cc: Dmitry Osipenko
> Cc: Laxman Dewangan (supporter:TEGRA DMA DRIVERS)
> Cc: Jon Hunter (supporter:TEGRA DMA DRIVERS)
> Cc: Vinod Koul (maintainer:DMA GENERIC
Add new property that designates the PMIC as the system's power
controller.
Signed-off-by: Dmitry Osipenko
---
Documentation/devicetree/bindings/mfd/max77620.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/max77620.txt
b/Documentation/devic
stem-power-controller" OF property.
Patch "Support device-tree properly" now doesn't remove driver's
"id_table" since potentially it could have some use in the downstream
kernel forks and it doesn't hurt to keep it around.
Dmitry Osipenko (6):
mf
Provide system power-off functionality that allows to turn off machine
gracefully.
Signed-off-by: Dmitry Osipenko
---
drivers/mfd/max77620.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/mfd/max77620.c b/drivers/mfd/max77620.c
index 9b0009c29610..e56223bde568
The FPS_PERIOD_MAX_US definitions are swapped for MAX20024 and MAX77620,
fix it.
Cc: stable
Signed-off-by: Dmitry Osipenko
---
include/linux/mfd/max77620.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/mfd/max77620.h b/include/linux/mfd/max77620.h
index
Add support for Maxim 77663 using the Max77620 driver. The hardware
is very similar to Max77663/20024, although there are couple minor
differences.
Signed-off-by: Dmitry Osipenko
---
drivers/mfd/max77620.c | 69 +++-
include/linux/mfd/max77620.h | 1 +
2
Maxim 77663 has a few minor differences in regards to hardware interface
and available capabilities by comparing it with 77620 and 20024 models,
hence re-use 77620 device-tree binding for the 77663.
Signed-off-by: Dmitry Osipenko
---
Documentation/devicetree/bindings/mfd/max77620.txt | 4
Add support for Maxim 77663.
Signed-off-by: Dmitry Osipenko
---
drivers/regulator/max77620-regulator.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/max77620-regulator.c
b/drivers/regulator/max77620-regulator.c
index
Use SPDX tag for the license identification instead of a free form text
to aid license-checking automation and for brevity.
Signed-off-by: Dmitry Osipenko
---
drivers/clocksource/timer-tegra20.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers
d the driver's code is getting much cleaner. Note that arch-timer usage
is discouraged on all Tegra's due to the time jitter caused by the CPU
frequency scaling.
Dmitry Osipenko (7):
clocksource/drivers/tegra: Support per-CPU timers on all Tegra's
clocksource/drivers/tegra: Unify time
Correct typo and use proper upper casing for acronyms in the comments,
use common style for error messages, prepend error messages with
"tegra-timer:", add error message for cpuhp_setup_state() failure and
clean up whitespaces in the code to fix checkpatch warnings.
Signed-off-by: Dmitr
10 has the
microseconds counter. Hence the delay timer and timer_us clocksource are
now made available for Tegra210 as well.
Signed-off-by: Dmitry Osipenko
---
drivers/clocksource/timer-tegra20.c | 111 +++-
1 file changed, 60 insertions(+), 51 deletions(-)
diff --git a/drivers/c
Reset timer's hardware state to ensure that initially it is in a
predictable state.
Signed-off-by: Dmitry Osipenko
---
drivers/clocksource/timer-tegra20.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/clocksource/timer-tegra20.c
b/drivers/clocksource/timer-tegra20.c
since there is no need for the memory-access syncing.
Signed-off-by: Dmitry Osipenko
---
drivers/clocksource/timer-tegra20.c | 38 ++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/clocksource/timer-tegra20.c
b/drivers/clocksource/timer-tegra20.c
Release all requested IRQ's on the request error to properly clean up
allocated resources.
Signed-off-by: Dmitry Osipenko
---
drivers/clocksource/timer-tegra20.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/clocksource/timer-tegra20.c
b/drivers/clocks
very
accurate due to the clock rate jitter caused by CPU frequency scaling.
Signed-off-by: Dmitry Osipenko
---
drivers/clocksource/timer-tegra20.c | 133
1 file changed, 56 insertions(+), 77 deletions(-)
diff --git a/drivers/clocksource/timer-tegra20.c
b/drivers/cl
ce use the relaxed versions of the functions.
Signed-off-by: Dmitry Osipenko
---
drivers/dma/tegra20-apb-dma.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
index cf462b1abc0b..e646e1c7b299 100644
--- a/d
Compilation fails if any of undeclared clk_set_*() functions are in use
and CONFIG_HAVE_CLK=n.
Reported-by: kbuild test robot
Signed-off-by: Dmitry Osipenko
---
include/linux/clk.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/linux/clk.h b/include/linux/clk.h
24.04.2019 11:36, Peter De Schrijver пишет:
> On Fri, Apr 19, 2019 at 02:50:10PM +0300, Dmitry Osipenko wrote:
>> 12.04.2019 0:48, Dmitry Osipenko пишет:
>>> Hello, here are two trivial patches that are correcting PLLM on Tegra124.
>>> First fixes system lockup due to a
25.04.2019 14:22, Thierry Reding пишет:
> On Thu, Apr 25, 2019 at 01:49:00AM +0300, Dmitry Osipenko wrote:
>> Provide system power-off functionality that allows to turn off machine
>> gracefully.
>>
>> Signed-off-by: Dmitry Osipenko
>> ---
>> drivers/mfd/ma
25.04.2019 18:14, Stephen Boyd пишет:
> Quoting Dmitry Osipenko (2019-04-25 06:50:39)
>> 24.04.2019 11:36, Peter De Schrijver пишет:
>>> On Fri, Apr 19, 2019 at 02:50:10PM +0300, Dmitry Osipenko wrote:
>>>> 12.04.2019 0:48, Dmitry Osipenko пишет:
>>>>
&
25.04.2019 22:07, Stephen Boyd пишет:
> Quoting Dmitry Osipenko (2019-04-14 13:20:06)
>> diff --git a/drivers/clk/tegra/clk-tegra20-emc.c
>> b/drivers/clk/tegra/clk-tegra20-emc.c
>> new file mode 100644
>> index ..35b67a9989c8
>> --- /dev/null
>&
26.04.2019 1:25, Stephen Boyd пишет:
> Quoting Dmitry Osipenko (2019-04-25 14:42:19)
>> 25.04.2019 22:07, Stephen Boyd пишет:
>>> Quoting Dmitry Osipenko (2019-04-14 13:20:06)
>>>> diff --git a/drivers/clk/tegra/clk-tegra20-emc.c
>>>> b/drivers/clk/
26.04.2019 3:41, Stephen Boyd пишет:
> Quoting Dmitry Osipenko (2019-04-25 17:03:11)
>> 26.04.2019 1:25, Stephen Boyd пишет:
>>> Quoting Dmitry Osipenko (2019-04-25 14:42:19)
>>>> 25.04.2019 22:07, Stephen Boyd пишет:
>>>>>
05.02.2019 4:29, Sowjanya Komatineni пишет:
> This patch adds DMA support for Tegra I2C.
>
> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
> transfer size of the max FIFO depth and DMA mode is used for
> transfer size higher than max FIFO depth to save CPU overhead.
>
> PIO mode
> Acked-by: Thierry Reding
> Reviewed-by: Dmitry Osipenko
> ---
timeout based on the transfer size
> and I2C bus rate to allow enough time during max transfer size at
> lower bus speed.
>
> Signed-off-by: Sowjanya Komatineni
> Acked-by: Thierry Reding
> Reviewed-by: Dmitry Osipenko
> ---
> [V10] : Reduced the timeout for bus clear ope
05.02.2019 4:37, Sowjanya Komatineni пишет:
>> I know that APB DMA driver enables flow control based on the channels spec,
>> but still won't hurt to explicitly show that channels are flow-controlled.
>> Ideally APB DMA driver should respect the device_fc field.
>>
>> dma_sconfig.dev
05.02.2019 11:56, Sowjanya Komatineni пишет:
> This patch adds DMA support for Tegra I2C.
>
> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
> transfer size of the max FIFO depth and DMA mode is used for
> transfer size higher than max FIFO depth to save CPU overhead.
>
> PIO mod
05.02.2019 11:56, Sowjanya Komatineni пишет:
> This patch adds I2C interface timing registers support for
> proper bus rate configuration along with meeting the i2c spec
> setup and hold times based on the tuning performed on Tegra210,
> Tegra186 and Tegra194 platforms.
>
> I2C_INTERFACE_TIMING_0
05.02.2019 19:41, Sowjanya Komatineni пишет:
>> Please use "./scripts/checkpatch.pl --strict *.patch" and fix all its
>> complains, but only those that really make sense. For example ignore the
>> "CHECK: Lines should not end with a '('" warnings.
>>
>> Here checkpatch recommends to use the BIT(
06.02.2019 1:46, Sowjanya Komatineni пишет:
> This patch adds DMA support for Tegra I2C.
>
> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
> transfer size of the max FIFO depth and DMA mode is used for
> transfer size higher than max FIFO depth to save CPU overhead.
>
> PIO mode
06.02.2019 1:46, Sowjanya Komatineni пишет:
> This patch adds DMA support for Tegra I2C.
>
> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
> transfer size of the max FIFO depth and DMA mode is used for
> transfer size higher than max FIFO depth to save CPU overhead.
>
> PIO mode
06.02.2019 14:55, Dmitry Osipenko пишет:
> 06.02.2019 1:46, Sowjanya Komatineni пишет:
>> This patch adds DMA support for Tegra I2C.
>>
>> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
>> transfer size of the max FIFO depth and DMA mode is used for
&
06.02.2019 15:48, Thierry Reding пишет:
> On Wed, Feb 06, 2019 at 03:40:52PM +0300, Dmitry Osipenko wrote:
>> 06.02.2019 1:46, Sowjanya Komatineni пишет:
>>> This patch adds DMA support for Tegra I2C.
>>>
>>> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode
06.02.2019 16:03, Sowjanya Komatineni пишет:
>> BTW, I'm seeing "atmel_mxt_ts 0-004c: Warning: Info CRC error -
>> device=0xF436DC file=0x00" whithout making any modifications to the
>> original patch as well and it shall not happen, hence there is bug
>> somewhere. Probably FIFO triggers ar
06.02.2019 15:49, Sowjanya Komatineni пишет:
>
>> TEGRA_I2C_TIMEOUT);
>>> tegra_i2c_mask_irq(i2c_dev, int_mask); @@ -814,6 +1133,7 @@ static
>>> int tegra_i2c_xfer_msg(struct tegra_i2c_dev *i2c_dev,
>>> time_left, completion_done(&i2c_dev->msg_complete),
>>>
06.02.2019 16:13, Thierry Reding пишет:
[snip]
>> That's odd because it suggests that DMA actually completed, but the
>> message didn't.
>>
>> I'm not sure I understand how that could happen.
>>
>> What's also weird above is that there doesn't seem to be a DMA that
>> is started for that particul
06.02.2019 16:17, Sowjanya Komatineni пишет:
>
>
BTW, I'm seeing "atmel_mxt_ts 0-004c: Warning: Info CRC error -
device=0xF436DC file=0x00" whithout making any modifications to the
original patch as well and it shall not happen, hence there is bug
somewhere. Probably FI
06.02.2019 16:30, Sowjanya Komatineni пишет:
>
>
>>>
>> BTW, I'm seeing "atmel_mxt_ts 0-004c: Warning: Info CRC error -
>> device=0xF436DC file=0x00" whithout making any modifications to the
>> original patch as well and it shall not happen, hence there is bug
>> somewhere.
06.02.2019 16:34, Dmitry Osipenko пишет:
> 06.02.2019 16:30, Sowjanya Komatineni пишет:
>>
>>
>>>>
>>>>>>> BTW, I'm seeing "atmel_mxt_ts 0-004c: Warning: Info CRC error -
>>>>>>> device=0xF436DC file=0x00" w
06.02.2019 16:25, Sowjanya Komatineni пишет:
>
>
That's odd because it suggests that DMA actually completed, but the
message didn't.
I'm not sure I understand how that could happen.
What's also weird above is that there doesn't seem to be a DMA that
is started
06.02.2019 17:01, Thierry Reding пишет:
> On Wed, Feb 06, 2019 at 01:51:12PM +, Sowjanya Komatineni wrote:
>>
>>> That's odd because it suggests that DMA actually completed, but
>>> the message didn't.
>>>
>>> I'm not sure I understand how that could happen.
>>>
>>> Wha
06.02.2019 17:19, Sowjanya Komatineni пишет:
> No, there are no timeout errors in PIO mode. I could post full log with
> the PIO-only mode if you want.
>
Yes please post full log of PIO only and DMA only Also, in above log,
lots of DMA transfer went thru fine except this one
06.02.2019 17:29, Sowjanya Komatineni пишет:
>
>> Yes please post full log of PIO only and DMA only Also, in above
>> log, lots of DMA transfer went thru fine except this one transfer
>> where DMA timed out.
>> DMA completion doesnt happen on DMA submit during this particular
>>
06.02.2019 17:53, Thierry Reding пишет:
> On Tue, Feb 05, 2019 at 05:26:25PM +0300, Dmitry Osipenko wrote:
> [...]
>> Oh, another important moment is that physically contiguous dma_buf
>> allocation isn't guaranteed by the DMA API. This may become a problem
>> for T186
06.02.2019 17:47, Sowjanya Komatineni пишет:
> This patch adds DMA support for Tegra I2C.
>
> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
> transfer size of the max FIFO depth and DMA mode is used for
> transfer size higher than max FIFO depth to save CPU overhead.
>
> PIO mod
06.02.2019 18:55, Sowjanya Komatineni пишет:
>
>
>>> Two ";;" at the end.
>>>
>>>
>>>
>>> Good news: DVC I2C works now and tps6586x probes fine! :) Bad news:
>>> atmel-touch still has same problems as in V12 :(
>>>
>>> DMA-only V13: http://dpaste.com/0XJ1Z8G.txt
>>
>> Strangely, there are many t
06.02.2019 19:07, Dmitry Osipenko пишет:
> 06.02.2019 18:55, Sowjanya Komatineni пишет:
>>
>>
>>>> Two ";;" at the end.
>>>>
>>>>
>>>>
>>>> Good news: DVC I2C works now and tps6586x probes fine! :) Bad news
06.02.2019 19:38, Sowjanya Komatineni пишет:
Looking into timestamps and transactions, DMA timeouts after start of DMA
for I2C1 to touch during this transaction.
While it is waiting for I2C1 DMA transfer, lots of DVC transactions
happened thru DMA which are successful
>>>
06.02.2019 17:56, Dmitry Osipenko пишет:
> 06.02.2019 17:53, Thierry Reding пишет:
>> On Tue, Feb 05, 2019 at 05:26:25PM +0300, Dmitry Osipenko wrote:
>> [...]
>>> Oh, another important moment is that physically contiguous dma_buf
>>> allocation isn't guaran
06.02.2019 22:56, Sowjanya Komatineni пишет:
>
> Oh, another important moment is that physically contiguous dma_buf
> allocation isn't guaranteed by the DMA API. This may become a
> problem for T186+ that can transfer up to 64K. We need to enforce
> the contiguous-allocation req
24.01.2019 23:51, Sowjanya Komatineni пишет:
> This patch adds DMA support for Tegra I2C.
>
> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
> transfer size of the max FIFO depth and DMA mode is used for
> transfer size higher than max FIFO depth to save CPU overhead.
>
> PIO mod
24.01.2019 23:51, Sowjanya Komatineni пишет:
> This patch prepares the buffer with the message bytes to be
> transmitted along with the packet header information and then
> performs i2c transfer in PIO mode.
>
> Signed-off-by: Sowjanya Komatineni
> ---
> [V2] : DMA support changes include prepar
25.01.2019 23:31, Sowjanya Komatineni пишет:
>
>>> + if (i2c_dev->has_dma) {
>>> + ret = tegra_i2c_init_dma_param(i2c_dev, true);
>>> + if (ret == -EPROBE_DEFER)
>>> + goto disable_div_clk;
>>> + ret = tegra_i2c_init_dma_param(i2c_dev, false);
>>>
25.01.2019 23:20, Sowjanya Komatineni пишет:
>
>
>>> This patch prepares the buffer with the message bytes to be
>>> transmitted along with the packet header information and then performs
>>> i2c transfer in PIO mode.
>>>
>>> Signed-off-by: Sowjanya Komatineni
>>> ---
>>> [V2] : DMA support c
26.01.2019 0:11, Sowjanya Komatineni пишет:
>
>
> + if (i2c_dev->has_dma) {
> + ret = tegra_i2c_init_dma_param(i2c_dev, true);
> + if (ret == -EPROBE_DEFER)
> + goto disable_div_clk;
> + ret = tegra_i2c_init_dma_param(i2c_dev, false);
>>
24.01.2019 23:51, Sowjanya Komatineni пишет:
> This patch adds DMA support for Tegra I2C.
>
> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
> transfer size of the max FIFO depth and DMA mode is used for
> transfer size higher than max FIFO depth to save CPU overhead.
>
> PIO mod
26.01.2019 0:49, Dmitry Osipenko пишет:
> 3) After applying these patches I2C transfers are failing on Tegra20 with
> "tegra-i2c 7000c400.i2c: Failed to allocate the DMA buffer".
>
Actually scratch the above, turned out I haven't applied patches correctly. In
fac
24.01.2019 23:51, Sowjanya Komatineni пишет:
> This patch adds DMA support for Tegra I2C.
>
> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
> transfer size of the max FIFO depth and DMA mode is used for
> transfer size higher than max FIFO depth to save CPU overhead.
>
> PIO mod
26.01.2019 0:25, Dmitry Osipenko пишет:
> 25.01.2019 23:20, Sowjanya Komatineni пишет:
>>
>>
>>>> This patch prepares the buffer with the message bytes to be
>>>> transmitted along with the packet header information and then performs
>>>>
24.01.2019 23:51, Sowjanya Komatineni пишет:
> This patch adds DMA support for Tegra I2C.
>
> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
> transfer size of the max FIFO depth and DMA mode is used for
> transfer size higher than max FIFO depth to save CPU overhead.
>
> PIO mod
26.01.2019 3:28, Dmitry Osipenko пишет:
> 24.01.2019 23:51, Sowjanya Komatineni пишет:
>> This patch adds DMA support for Tegra I2C.
>>
>> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
>> transfer size of the max FIFO depth and DMA mode is used for
&
26.01.2019 6:57, Sowjanya Komatineni пишет:
> This patch adds DMA support for Tegra I2C.
>
> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
> transfer size of the max FIFO depth and DMA mode is used for
> transfer size higher than max FIFO depth to save CPU overhead.
>
> PIO mode
26.01.2019 6:57, Sowjanya Komatineni пишет:
> This patch adds DMA support for Tegra I2C.
>
> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
> transfer size of the max FIFO depth and DMA mode is used for
> transfer size higher than max FIFO depth to save CPU overhead.
>
> PIO mode
26.01.2019 6:57, Sowjanya Komatineni пишет:
> -#include
> -#include
> -#include
> #include
> +#include
> #include
> #include
> -#include
> +#include
> #include
> -#include
> -#include
> -#include
> +#include
> +#include
> +#include
> #include
> -#include
> +#include
> #incl
26.01.2019 6:57, Sowjanya Komatineni пишет:
> Update I2C transfer timeout based on transfer bytes and I2C bus
> rate to allow enough time during max transfer size based on the
> speed.
Could it be that I2C device is busy and just slowly handling the transfer
requests? Maybe better to leave the ti
26.01.2019 20:11, Dmitry Osipenko пишет:
> 26.01.2019 6:57, Sowjanya Komatineni пишет:
>> This patch adds DMA support for Tegra I2C.
>>
>> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
>> transfer size of the max FIFO depth and DMA mode is used for
&
26.01.2019 6:57, Sowjanya Komatineni пишет:
> This patch adds DMA support for Tegra I2C.
>
> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
> transfer size of the max FIFO depth and DMA mode is used for
> transfer size higher than max FIFO depth to save CPU overhead.
>
> PIO mode
26.01.2019 6:57, Sowjanya Komatineni пишет:
> This patch adds DMA support for Tegra I2C.
>
> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
> transfer size of the max FIFO depth and DMA mode is used for
> transfer size higher than max FIFO depth to save CPU overhead.
>
> PIO mode
18.03.2019 1:52, Dmitry Osipenko пишет:
> Hello,
>
> This patchset adds support for the Trusted Foundations firmware on
> NVIDIA Tegra30. Pretty much all of Tegra30 consumer devices have that
> firmware and upstream kernel can't boot on those devices without the
> firmwa
05.02.2019 14:16, Sameer Pujar пишет:
> Drivers need to handle !PM case with work arounds for managing clocks
> and power explicitly, which is not really necessary when PM support on
> tegra is in good shape. In fact ARM 64-bit tegra platforms enforce PM
Tegra
> support and there is no reason why
25.02.2019 19:58, Robert Yang пишет:
> On Mon, Feb 25, 2019 at 08:21:55AM +0300, Dmitry Osipenko wrote:
>> В Mon, 25 Feb 2019 05:02:33 +0100
>> Michał Mirosław пишет:
>>
>>> On Fri, Feb 22, 2019 at 10:34:19PM +0300, Dmitry Osipenko wrote:
>>>> Hello,
&g
26.02.2019 13:56, Greg Kroah-Hartman пишет:
> On Mon, Feb 25, 2019 at 08:07:15AM +0300, Dmitry Osipenko wrote:
>> В Mon, 25 Feb 2019 02:27:19 +
>> Peter Chen пишет:
>>
>>>
>>>>
>>>> Fixes: dfebb5f43a78827a ("usb: chipidea: Add su
26.02.2019 11:25, Sameer Pujar пишет:
> The requirement for this came while adding runtime PM support for HDA
> driver. There were concerns about driver explicitly handling !PM case.
> In general, drivers need to handle !PM case with work arounds for
> managing clocks and power explicitly, which is
26.02.2019 17:58, Greg Kroah-Hartman пишет:
> On Tue, Feb 26, 2019 at 05:33:05PM +0300, Dmitry Osipenko wrote:
>> 26.02.2019 13:56, Greg Kroah-Hartman пишет:
>>> On Mon, Feb 25, 2019 at 08:07:15AM +0300, Dmitry Osipenko wrote:
>>>> В Mon, 25 Feb 2019 02:27:1
26.02.2019 18:21, Greg Kroah-Hartman пишет:
> On Tue, Feb 26, 2019 at 06:08:17PM +0300, Dmitry Osipenko wrote:
>> 26.02.2019 17:58, Greg Kroah-Hartman пишет:
>>> On Tue, Feb 26, 2019 at 05:33:05PM +0300, Dmitry Osipenko wrote:
>>>> 26.02.2019 13:56, Greg Kroah-Hartm
26.02.2019 12:13, Russell King - ARM Linux admin пишет:
> On Tue, Feb 26, 2019 at 01:55:37PM +0530, Sameer Pujar wrote:
>> The requirement for this came while adding runtime PM support for HDA
>> driver. There were concerns about driver explicitly handling !PM case.
>> In general, drivers need to h
e commit message is okay to me this time, thanks! I'm still not super-happy
to lose the !PM option because of its value in regards to the PM debugging, but
again we can just do something better in that regards later on if will be
really needed.
Reviewed-by: Dmitry Osipenko
24.02.2019 18:34, Dmitry Osipenko пишет:
> Tiling modifier can't be applied to YV12 video overlay because all tiling
> modifiers are filtered out for multi-plane formats. AFAIK, all modifiers
> should work with all of formats, hence the checking is incorrect and
> simply not n
24.02.2019 18:32, Dmitry Osipenko пишет:
> Initially Common Clock Framework isn't aware of the clock-enable status,
> this results in enabling of clocks that were enabled by bootloader. This
> is not a big deal for a regular clock-gates, but for PLL's it may have
> some u
23.02.2021 05:13, Nicolin Chen пишет:
> Hi Dmitry,
>
> On Sat, Feb 20, 2021 at 08:16:22AM +0300, Dmitry Osipenko wrote:
>> 19.02.2021 01:07, Nicolin Chen пишет:
>>> Commit 25938c73cd79 ("iommu/tegra-smmu: Rework tegra_smmu_probe_device()")
>>> remove
18.02.2021 22:56, Alexandre Belloni пишет:
> Hello,
>
> I just wanted to thank you for reporting this issue. I didn't yet have
> the time to work on that but this is on my radar. There is also another
> issue when resuming and I'm not yet sure how we can solve it for all
> platforms.
No problems,
501 - 600 of 4295 matches
Mail list logo
