ions
echo 1 > /sys/module/dmatest/parameters/max_channels
Prior to this patch: ~1.3 GB/s
After this patch: ~1.8 GB/s
with 1 byte alignment: ~1.7 GB/s
Regards,
Peter
---
Peter Ujfalusi (3):
dmaengine: Extend the dmaengine_alignment for 128 and 256 bytes
dmaengine: ti: k3-udma:
From: Peter Ujfalusi
The UDMA and BCDMA can provide higher throughput if the burst_size of the
channel is changed from it's default (which is 64 bytes) for Ultra-high
and high capacity channels.
This performance benefit is even more visible when the buffers are aligned
with the burst_size
From: Peter Ujfalusi
Some DMA device can benefit with higher order of alignment than the maximum
of 64 bytes currently defined.
Define 128 and 256 bytes alignment for these devices.
Signed-off-by: Peter Ujfalusi
Signed-off-by: Peter Ujfalusi
Tested-by: Kishon Vijay Abraham I
---
include
The ret does not need to be initialized to 0 in the tisci channel config
functions.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index
-off-by: Peter Ujfalusi
---
.../devicetree/bindings/display/bridge/toshiba,tc358768.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml
b/Documentation/devicetree/bindings/display/bridge/toshiba
Hi Sam,
On 17/12/2020 19.25, Sam Ravnborg wrote:
>>> dtschema/dtc warnings/errors:
>>> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml:
>>> 'maintainers' is a required property
>>>
Instead of initializing the rchan_tpl the initial commit re-initialized
the tchan_tpl.
Fixes: d2abc982333c0 ("dmaengine: ti: k3-udma: Initial support for K3 PKTDMA")
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletion
On 15/12/2020 16.26, Rob Herring wrote:
> On Tue, 15 Dec 2020 14:42:27 +0200, Peter Ujfalusi wrote:
>> My employment with TI is coming to an end and I will not have access to
>> the board where this bridge is connected to.
>>
>> It is better to remove a soon bouncing
My employment with TI is coming to an end, add the copyright and author comments
as they due and change the maintainer mail address.
Signed-off-by: Peter Ujfalusi
Signed-off-by: Peter Ujfalusi
---
Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml | 4 +++-
Documentation/devicetree
Hi,
My TI address is going to bounce after Friday (18.12.2020), switch my address to
my private one for now.
Regards,
Peter
---
Peter Ujfalusi (2):
MAINTAINERS: Add entry for Texas Instruments DMA drivers
dt-bindings: dma: ti: Update maintainer and author information
.../devicetree
My employment with TI is coming to an end, it is my intention to look after
the DMA drivers I have worked with over the years.
Signed-off-by: Peter Ujfalusi
Signed-off-by: Peter Ujfalusi
---
MAINTAINERS | 13 +
1 file changed, 13 insertions(+)
diff --git a/MAINTAINERS b
My employment with TI is coming to an end, add the copyright and author comments
as they due and change the maintainer mail address.
Signed-off-by: Peter Ujfalusi
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/sound/ti,j721e-cpb-audio.yaml | 4 +++-
.../devicetree/bindings
Hi,
On 15/12/2020 15.05, Peter Ujfalusi wrote:
> Hi,
>
> My TI address is going to bounce after Friday (18.12.2020), switch my email
> address to my private one for now.
Obviously I forgot to 'TO' the private myself...
Doing that now.
>
> Regards,
> Peter
>
My employment with TI is coming to an end, it is my intention to look after
the drivers I have worked with over the years.
Signed-off-by: Peter Ujfalusi
Signed-off-by: Peter Ujfalusi
---
MAINTAINERS | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b
Hi,
My TI address is going to bounce after Friday (18.12.2020), switch my email
address to my private one for now.
Regards,
Peter
---
Peter Ujfalusi (2):
MAINTAINERS: Update email address for TI ASoC and twl4030 codec
drivers
ASoC: dt-bindings: ti,j721e: Update maintainer and author
My employment with TI is coming to an end and I will not have access to
the board where this bridge is connected to.
It is better to remove a soon bouncing email address.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/display/bridge/toshiba,tc358768.yaml | 3 ---
1 file changed, 3
Some DMA device can benefit with higher order of alignment than the maximum
of 64 bytes currently defined.
Define 128 and 256 bytes alignment for these devices.
Signed-off-by: Peter Ujfalusi
---
include/linux/dmaengine.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux
000 > /sys/module/dmatest/parameters/timeout
echo 50 > /sys/module/dmatest/parameters/iterations
echo 1 > /sys/module/dmatest/parameters/max_channels
Prior this patch: ~1.3 GB/s
After this patch: ~1.8 GB/s
with 1 byte alignment: ~1.7 GB/s
Signed-off-by: Peter Ujfalusi
---
dr
t/parameters/max_channels
Prior to this patch: ~1.3 GB/s
After this patch: ~1.8 GB/s
with 1 byte alignment: ~1.7 GB/s
The patches are on top of the AM64 support series:
https://lore.kernel.org/lkml/20201208090440.31792-1-peter.ujfal...@ti.com/
Regards,
Peter
---
Peter Ujfalusi (2):
dmaen
Use ERR_CAST() when devm_ioremap_resource() fails.
Reported-by: kernel test robot
Signed-off-by: Peter Ujfalusi
---
Hi Vinod,
it came to my attention too late. This patch fixes the sparse warnig introduced
by the AM64 support in
https://lore.kernel.org/lkml/20201208090440.31792-1-peter.ujfal
Hi Vinod,
On 11/12/2020 18.24, Vinod Koul wrote:
> On 08-12-20, 11:04, Peter Ujfalusi wrote:
>> Hi,
>>
>> The series have build dependency on ti_sci/soc series (v2):
>> https://lore.kernel.org/lkml/20201008115224.1591-1-peter.ujfal...@ti.com/
>>
>> Santosh k
On 08/12/2020 11.04, Peter Ujfalusi wrote:
> From: Grygorii Strashko
>
> The DMAs in AM64 have built in rings compared to AM654/J721e/J7200 where a
> separate and generic ringacc is used.
>
> The ring SW interface is similar to ringacc with some major architectural
&
the peripheral.
Regards,
Peter
---
Grygorii Strashko (1):
soc: ti: k3-ringacc: add AM64 DMA rings support.
Peter Ujfalusi (18):
dmaengine: ti: k3-udma: Correct normal channel offset when uchan_cnt
is not 0
dmaengine: ti: k3-udma: Wait for peer teardown completion if supported
dmaengine: ti: k3
Add initial PSI-L map file for AM64.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/Makefile | 3 +-
drivers/dma/ti/k3-psil-am64.c | 158 ++
drivers/dma/ti/k3-psil-priv.h | 1 +
drivers/dma/ti/k3-psil.c | 1 +
4 files changed, 162 insertions
Client drivers should use the dmaengine_get_dma_device(chan) to get the
device pointer which should be used for DMA API for allocations and
mapping.
Signed-off-by: Peter Ujfalusi
---
Documentation/driver-api/dmaengine/client.rst | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
Additional fields needed for K3 PKTDMA to be able to handle the mapped
channels (channels are locked to handle specific threads) and flow ranges
for these mapped threads.
PKTDMA also introduces tflow for tx channels which can not be found in
K3 UDMA architecture.
Signed-off-by: Peter Ujfalusi
the DMAs.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-private.c | 9 +
drivers/dma/ti/k3-udma.c | 545 +--
drivers/dma/ti/k3-udma.h | 4 +
3 files changed, 533 insertions(+), 25 deletions(-)
diff --git a/drivers/dma/ti/k3-udma-private.c b
New binding document for
Texas Instruments K3 Block Copy DMA (BCDMA).
BCDMA is introduced as part of AM64.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/dma/ti/k3-bcdma.yaml | 164 ++
1 file changed, 164 insertions(+)
create mode 100644 Documentation/devicetree
to support BCDMA channel TPL we need to move the tpl information
as per channel type property for the DMAs.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma.c | 117 ++-
drivers/dma/ti/k3-udma.h | 6 ++
2 files changed, 85 insertions(+), 38 deletions
to that RX
channel.
Signed-off-by: Vignesh Raghavendra
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-glue.c| 291 +++
drivers/dma/ti/k3-udma-private.c | 24 +++
drivers/dma/ti/k3-udma.h | 4 +
include/linux/dma/k3-udma-glue.h | 8 +
4 files
ma_dev = dmaengine_get_dma_device(chan);
+
+ dma_map_single(dma_dev, ptr, size, DMA_TO_DEVICE);
Signed-off-by: Peter Ujfalusi
---
include/linux/dmaengine.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index aed44888cad3..68130f5f599e
By using the dmaengine_get_dma_device() to get the device for
dma_api use, the dmatest can support per channel coherency if it is
supported by the DMA controller.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/dmatest.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff
to service peripherals directly if an external
trigger is selected for the channel.
Most of the driver code can be reused for BCDMA bchan/tchan/rchan support
but new setup and allocation functions are needed to handle the
differences between the DMAs.
Signed-off-by: Peter Ujfalusi
---
drivers
() as it is not an independent device as ringacc
is.
AM64 rings must be requested only using k3_ringacc_request_rings_pair(),
and forward ring must always be initialized/configured. After this any
other Ringacc APIs can be used without any callers changes.
Signed-off-by: Grygorii Strashko
Signed-off-by: Peter
Set the TDTYPE if it is supported on the platform (j721e) which will cause
UDMAP to wait for the remote peer to finish the teardown before returning
the teardown completed message.
Signed-off-by: Peter Ujfalusi
Tested-by: Keerthy
Reviewed-by: Grygorii Strashko
---
drivers/dma/ti/k3-udma.c
If of_xudma_dev_get() returns with the valid udma_dev then the driver
already got the ringacc, there is no need to execute
of_k3_ringacc_get_by_phandle() for each channel via the glue layer.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-glue.c| 6 +-
drivers/dma/ti/k3-udma
Resource allocation via sysfw can use up to two ranges per resource subtype
to support more complex resource assignment, mainly for DMA channels.
Take the second range also into consideration when setting up the maps for
available resources.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3
Glue layer users should use the device of the DMA for DMA mapping and
allocations as it is the DMA which accesses to descriptors and buffers,
not the clients
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-glue.c| 14 ++
drivers/dma/ti/k3-udma-private.c | 6
Signed-off-by: Peter Ujfalusi
---
include/linux/dma/k3-event-router.h | 16
1 file changed, 16 insertions(+)
create mode 100644 include/linux/dma/k3-event-router.h
diff --git a/include/linux/dma/k3-event-router.h
b/include/linux/dma/k3-event-router.h
new file mode 100644
index
New binding document for
Texas Instruments K3 Packet DMA (PKTDMA).
PKTDMA is introduced as part of AM64.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/dma/ti/k3-pktdma.yaml | 172 ++
1 file changed, 172 insertions(+)
create mode 100644 Documentation/devicetree
.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-glue.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index 8a8988be4175..e6ebcd98c02a 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
is in use, then the driver can implement the device_router_config
callback.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/of-dma.c | 10 ++
include/linux/dmaengine.h | 2 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index 8a4f608904b9
According to different sections of the TRM, the hchan_cnt of CAP3 includes
the number of uchan in UDMA, thus the start offset of the normal channels
are hchan_cnt.
Fixes: daf4ad0499aa4 ("dmaengine: ti: k3-udma: Query throughput level
information from hardware")
Signed-off-by: Pete
Hi Rob,
On 07/12/2020 21.42, Rob Herring wrote:
> On Tue, Nov 17, 2020 at 12:56:47PM +0200, Peter Ujfalusi wrote:
>> New binding document for
>> Texas Instruments K3 Block Copy DMA (BCDMA).
>>
>> BCDMA is introduced as part of AM64.
>>
>> Signed-off-by: Pe
Hi Santosh,
On 24/11/2020 19.08, Vinod Koul wrote:
> On 17-11-20, 12:56, Peter Ujfalusi wrote:
>> Hi,
>>
>> The series have build dependency on ti_sci/soc series (v2):
>> https://lore.kernel.org/lkml/20201008115224.1591-1-peter.ujfal...@ti.com/
>>
>>
The dev_release must be provided for a device and in case of the udma glue
layer it is in essence an empty function as the struct containing the
registered device is devm managed.
Reported-by: Vignesh Raghavendra
Signed-off-by: Peter Ujfalusi
---
Hi,
now that we actually have the silicon
Hi Viorel,
On 19/11/2020 18.24, Viorel Suman wrote:
> Hi Peter,
>
>> DTS is supposed to look as follows:
>>>
>>> / {
>>> ak4458_reset: gpio-reset {
>>>compatible = "gpio-reset";
>>>reset-gpios = < 4 GPIO_ACTIVE_LOW>;
>>>#reset-cells = <0>;
>>>
The J7200 SOM have additional io expander which is used to control several
SOM level muxes to make sure that the correct signals are routed to the
correct pin on the SOM <-> CPB connectors.
Signed-off-by: Peter Ujfalusi
Reviewed-by: Vignesh Raghavendra
---
.../dts/ti/k3-j7200-commo
J7200 main_i2c1 is connected to the i2c bus on the CPB marked as main_i2c3
The i2c1 devices on the CPB are _not_ connected to the SoC, they are not
usable with the J7200 SOM.
Correct the expander name from exp4 to exp3 and at the same time add the
line names as well.
Signed-off-by: Peter
, it is connected to
i2c3, so the devices on the CPB's i2c1 bus are not avalible, but the ones on the
CPB i2c3 are available under the main_i2c1.
Add nice line names at the same time to these.
Regards,
Peter
---
Peter Ujfalusi (2):
arm64: dts: ti: k3-j7200-som-p0: main_i2c0 have an ioexpander
On 19/11/2020 18.10, Vignesh Raghavendra wrote:
>
>
> On 11/19/20 6:56 PM, Peter Ujfalusi wrote:
>> J7200 main_i2c1 is connected to the i2c bus on the CPB marked as main_i2c3
>>
>> The i2c1 devices on the CPB are _not_ connected to the SoC, they are not
&
J7200 main_i2c1 is connected to the i2c bus on the CPB marked as main_i2c3
The i2c1 devices on the CPB are _not_ connected to the SoC, they are not
usable with the J7200 SOM.
Correct the expander name from exp4 to exp3 and at the same time add the
line names as well.
Signed-off-by: Peter
It is used to control several SOM level muxes to make sure that the correct
signals are routed to the correct pin on the SOM <-> CPB connectors.
Signed-off-by: Peter Ujfalusi
---
.../dts/ti/k3-j7200-common-proc-board.dts | 11
arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
are available under the main_i2c1.
Add nice line names at the same time to these.
Regards,
Peter
---
Peter Ujfalusi (2):
arm64: dts: ti: k3-j7200-som-p0: main_i2c0 have an ioexpander on the
SOM
arm64: dts: ti: k3-j7200-common-proc-board: Correct the name of io
expander on main_i2c1
.../dts
Hi,
On 17/11/2020 0.20, Viorel Suman (OSS) wrote:
> From: Viorel Suman
>
> Using GPIO API seems not a way to go for the case
> when the same reset GPIO is used to control several codecs.
> For a such case we can use the "gpio-reset" driver
> and the "shared" reset API to manage the reset GPIO -
The board is using McASP2 for both analog (tlv320aic3106) and
HDMI (SiI9022) audio.
12.288MHz oscillator provides the MCLK for both aic3106 and SiI9022.
Signed-off-by: Peter Ujfalusi
---
Hi,
Changes since v1:
- Rename the sii9022_mclk ficed clock to aud_mclk (as it is named in the schema
Hi,
On 17/11/2020 12.17, Peter Ujfalusi wrote:
> The board is using McASP2 for both analog (tlv320aic3106) and
> HDMI (SiI9022) audio.
>
> Signed-off-by: Peter Ujfalusi
> ---
> arch/arm/boot/dts/keystone-k2g-evm.dts | 112 +
> 1 file changed, 112 in
the DMAs.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-private.c | 9 +
drivers/dma/ti/k3-udma.c | 545 +--
drivers/dma/ti/k3-udma.h | 4 +
3 files changed, 533 insertions(+), 25 deletions(-)
diff --git a/drivers/dma/ti/k3-udma-private.c b
to service peripherals directly if an external
trigger is selected for the channel.
Most of the driver code can be reused for BCDMA bchan/tchan/rchan support
but new setup and allocation functions are needed to handle the
differences between the DMAs.
Signed-off-by: Peter Ujfalusi
---
drivers
situation:
The router needs to know the event number to send which in turn depends on the
channel we got for servicing the peripheral.
Regards,
Peter
---
Grygorii Strashko (1):
soc: ti: k3-ringacc: add AM64 DMA rings support.
Peter Ujfalusi (17):
dmaengine: ti: k3-udma: Correct normal channel offset
Glue layer users should use the device of the DMA for DMA mapping and
allocations as it is the DMA which accesses to descriptors and buffers,
not the clients
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-glue.c| 14 ++
drivers/dma/ti/k3-udma-private.c | 6
to support BCDMA channel TPL we need to move the tpl information
as per channel type property for the DMAs.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma.c | 117 ++-
drivers/dma/ti/k3-udma.h | 6 ++
2 files changed, 85 insertions(+), 38 deletions
Add initial PSI-L map file for AM64.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/Makefile | 3 +-
drivers/dma/ti/k3-psil-am64.c | 75 +++
drivers/dma/ti/k3-psil-priv.h | 1 +
drivers/dma/ti/k3-psil.c | 1 +
4 files changed, 79 insertions(+), 1
to that RX
channel.
Signed-off-by: Vignesh Raghavendra
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-glue.c| 272 ++-
drivers/dma/ti/k3-udma-private.c | 24 +++
drivers/dma/ti/k3-udma.h | 4 +
include/linux/dma/k3-udma-glue.h | 8 +
4 files
Signed-off-by: Peter Ujfalusi
---
include/linux/dma/k3-event-router.h | 16
1 file changed, 16 insertions(+)
create mode 100644 include/linux/dma/k3-event-router.h
diff --git a/include/linux/dma/k3-event-router.h
b/include/linux/dma/k3-event-router.h
new file mode 100644
index
() as it is not an independent device as ringacc
is.
AM64 rings must be requested only using k3_ringacc_request_rings_pair(),
and forward ring must always be initialized/configured. After this any
other Ringacc APIs can be used without any callers changes.
Signed-off-by: Grygorii Strashko
Signed-off-by: Peter
New binding document for
Texas Instruments K3 Packet DMA (PKTDMA).
PKTDMA is introduced as part of AM64.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/dma/ti/k3-pktdma.yaml | 183 ++
1 file changed, 183 insertions(+)
create mode 100644 Documentation/devicetree
Additional fields needed for K3 PKTDMA to be able to handle the mapped
channels (channels are locked to handle specific threads) and flow ranges
for these mapped threads.
PKTDMA also introduces tflow for tx channels which can not be found in
K3 UDMA architecture.
Signed-off-by: Peter Ujfalusi
ma_dev = dmaengine_get_dma_device(chan);
+
+ dma_map_single(dma_dev, ptr, size, DMA_TO_DEVICE);
Signed-off-by: Peter Ujfalusi
---
include/linux/dmaengine.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index d6197fe875af..182a1a2e7793
New binding document for
Texas Instruments K3 Block Copy DMA (BCDMA).
BCDMA is introduced as part of AM64.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/dma/ti/k3-bcdma.yaml | 175 ++
1 file changed, 175 insertions(+)
create mode 100644 Documentation/devicetree
Client drivers should use the dmaengine_get_dma_device(chan) to get the
device pointer which should be used for DMA API for allocations and
mapping.
Signed-off-by: Peter Ujfalusi
---
Documentation/driver-api/dmaengine/client.rst | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
By using the dmaengine_get_dma_device() to get the device for
dma_api use, the dmatest can support per channel coherency if it is
supported by the DMA controller.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/dmatest.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff
.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-glue.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index 29d1524d1916..ddf0730aa2bc 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
is in use, then the driver can implement the device_router_config
callback.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/of-dma.c | 10 ++
include/linux/dmaengine.h | 2 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index 8a4f608904b9
Set the TDTYPE if it is supported on the platform (j721e) which will cause
UDMAP to wait for the remote peer to finish the teardown before returning
the teardown completed message.
Signed-off-by: Peter Ujfalusi
Tested-by: Keerthy
Reviewed-by: Grygorii Strashko
---
drivers/dma/ti/k3-udma.c
According to different sections of the TRM, the hchan_cnt of CAP3 includes
the number of uchan in UDMA, thus the start offset of the normal channels
are hchan_cnt.
Fixes: daf4ad0499aa4 ("dmaengine: ti: k3-udma: Query throughput level
information from hardware")
Signed-off-by: Pete
Resource allocation via sysfw can use up to two ranges per resource subtype
to support more complex resource assignment, mainly for DMA channels.
Take the second range also into consideration when setting up the maps for
available resources.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3
The board is using McASP2 for both analog (tlv320aic3106) and
HDMI (SiI9022) audio.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/keystone-k2g-evm.dts | 112 +
1 file changed, 112 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts
b/arch/arm/boot
Hi Vinod,
On 09/11/2020 10.54, Vinod Koul wrote:
> This controller provides DMAengine capabilities for a variety of peripheral
> buses such as I2C, UART, and SPI. By using GPI dmaengine driver, bus
> drivers can use a standardize interface that is protocol independent to
> transfer data between
Kirill,
On 15/11/2020 14.23, Kirill Marinushkin wrote:
> Set format from `set_fmt()` func instead of `hw_params()`, plus supportive
> commits
Thank you for the clean series!
Reviewed-by: Peter Ujfalusi
> Kirill Marinushkin (4):
> ASoC: pcm512x: Fix not setting word length if DA
Hi Kirill,
On 12/11/2020 9.57, Kirill Marinushkin wrote:
>> The set_fmt callback is there to set the bus format, it has nothing to
>> do (in most cases) with the sample format (hw_params). Bus coding, clock
>> source has nothing to do with hw_params.
>>
>> When you bind a link you will use
need a write of 1 to register 41 (PCM512x_I2S_2, offset = 1), other
>> formats should set the offset to 0.
>
> That's a good idea, than you for technical details! I just didn't know how to
> use DSP_A and DSP_B. I will add them, and submit as patch v2
Great!
Thanks
- Péter
> Best
> sound card `sound/soc/bcm/hifiberry_dacplus.c`
>
> Signed-off-by: Kirill Marinushkin
> Cc: Mark Brown
> Cc: Takashi Iwai
> Cc: Liam Girdwood
> Cc: Matthias Reichl
> Cc: Kuninori Morimoto
> Cc: Peter Ujfalusi
> Cc: alsa-de...@alsa-project.org
> Cc: linux-
On 09/11/2020 14.23, Vinod Koul wrote:
> HI Peter,
>
> On 09-11-20, 14:09, Peter Ujfalusi wrote:
>> Hi Vinod,
>>
>> On 09/11/2020 13.45, Vinod Koul wrote:
>>>> Without a channel number I can not do anything.
>>>> It is close to a chicken and
Hi Vinod,
On 09/11/2020 13.45, Vinod Koul wrote:
>> Without a channel number I can not do anything.
>> It is close to a chicken and egg problem.
>
> We get 'channel' in xlate, so wont that help? I think I am still missing
> something here :(
Yes, we get channel in xlate, but we get the channel
On 06/11/2020 23.46, Nishanth Menon wrote:
> On 13:32-20201106, Peter Ujfalusi wrote:
> [...]
>>>
>>>>
>>>>> default power management functionality etc
>>>>
>>>> Right, so how does that helps with devices present in the SoC, but
Nishanth,
On 05/11/2020 16.08, Nishanth Menon wrote:
> On 09:32-20201105, Peter Ujfalusi wrote:
>> Nishanth,
>>
>> On 05/11/2020 0.43, Nishanth Menon wrote:
>>> The device tree standard sets the default node behavior when status
>>> property as enabled.
tatus='okay' is no longer necessary for mcasp10 and depends on the
> default state.
>
> [1]
> https://lore.kernel.org/linux-arm-kernel/20201027130701.ge5...@atomide.com/
>
> Fixes: 1c4d35265fb2 ("arm64: dts: ti: k3-j721e-main: Add McASP nodes")
> Fixes: 76921f15a
The following commit has been merged into the irq/urgent branch of tip:
Commit-ID: 82768a86c64659c7181571ebfbc41ec9f2e52dde
Gitweb:
https://git.kernel.org/tip/82768a86c64659c7181571ebfbc41ec9f2e52dde
Author:Peter Ujfalusi
AuthorDate:Tue, 03 Nov 2020 15:50:04 +02:00
sifive-plic: Fix broken irq_set_affinity() callback
>> irqchip/sifive-plic: Fix chip_data access within a hierarchy
>>
>> Marc Zyngier (4):
>> genirq: Let GENERIC_IRQ_IPI select IRQ_DOMAIN_HIERARCHY
>> irqchip/mst: Make mst_intc_of_init static
>> irqc
One space has been missing by the diagram update.
Fixes: bb2bd7c7f3d0 ("dt-bindings: irqchip: ti, sci-inta: Update for unmapped
event handling")
Reported-by: Rob Herring
Signed-off-by: Peter Ujfalusi
---
Hi,
I'm very sorry, I did not realized the missing whitespace in the orig
Eduardo, Keerthy,
On 29/10/2020 12.51, Tony Lindgren wrote:
> * Peter Ujfalusi [201029 10:03]:
>> Disabling the notifier fixes the random shutdowns on OMAP4430 (ES2.0 and
>> ES2.1)
>> but it does not cause any issues on OMAP4460 (PandaES) or OMAP3630
>> (B
On 29/10/2020 10.25, Xu Wang wrote:
> Because clk_disable_unprepare() already checked NULL clock parameter,
> so the additional check is unnecessary, just remove it.
Acked-by: Peter Ujfalusi
> Signed-off-by: Xu Wang
> ---
> sound/soc/ti/davinci-evm.c | 3 +--
> 1 file ch
such situation do PSI-L threads pairing only when UDMA
> channel is going to be enabled as at this time DMA consumer module expected
> to be active already.
Is this patch on top of the AM64 (BCDMA/PKTDMA) series or not?
Will it cause any conflict?
Acked-by: Peter Ujfalusi
> Si
The following commit has been merged into the irq/urgent branch of tip:
Commit-ID: bb2bd7c7f3d0946acc2104db31df228d10f7b598
Gitweb:
https://git.kernel.org/tip/bb2bd7c7f3d0946acc2104db31df228d10f7b598
Author:Peter Ujfalusi
AuthorDate:Tue, 20 Oct 2020 10:32:42 +03:00
The following commit has been merged into the irq/urgent branch of tip:
Commit-ID: d95bdca75b3fb41bf185efe164e05aed820081a5
Gitweb:
https://git.kernel.org/tip/d95bdca75b3fb41bf185efe164e05aed820081a5
Author:Peter Ujfalusi
AuthorDate:Tue, 20 Oct 2020 10:32:43 +03:00
nable addition power
management")
Signed-off-by: Peter Ujfalusi
---
Hi,
my omap4-sdp (Blaze) was shutting down randomly due to critical temperature with
5.10-rc1 and I have bisected it back to 5093402e5b44.
Disabling the notifier fixes the random shutdowns on OMAP4430 (ES2.0 and ES2.1)
but it does
Hi Vinod,
On 28/10/2020 7.55, Vinod Koul wrote:
>> To summarize:
>> In of_dma_route_allocate() the router does not yet know the channel we
>> are going to get.
>> In of_dma_xlate() the DMA driver does not yet know if the channel will
>> use router or not.
>> I need to tell the router the event
On 27/10/2020 15.07, Tony Lindgren wrote:
> * Nishanth Menon [201026 14:58]:
>> On 13:38-20201007, Peter Ujfalusi wrote:
>> [...]
>>>>>>> + status = "disabled";
>>>>>>
>>>>>> I see that there is
s case, false has the same numerical value as
> UDMA_TP_NORMAL, so passing that is most likely the correct
> way to avoid the warning without changing the behavior.
Yes, that's correct, thanks for fixing it!
Acked-by: Peter Ujfalusi
> Fixes: d70241913413 ("dmaengine: ti: k3-udma: Add glue layer for
1 - 100 of 4568 matches
Mail list logo
