Hi Alice,
On 4/19/21 7:27 AM, Alice Guo (OSS) wrote:
> From: Alice Guo
>
> Update all the code that use soc_device_match because add support for
> soc_device_match returning -EPROBE_DEFER.
>
> Signed-off-by: Alice Guo
> ---
> drivers/bus/ti-sysc.c | 2 +-
>
On 4/6/21 8:10 PM, Pratyush Yadav wrote:
> On 06/04/21 10:25PM, Pratyush Yadav wrote:
>> On 06/04/21 06:33PM, Péter Ujfalusi wrote:
>>>
>>>
>>> On 4/6/21 6:09 PM, Pratyush Yadav wrote:
>>>> On 04/04/21 04:24PM, Péter Ujfalusi wrote:
>>>
On 4/6/21 6:09 PM, Pratyush Yadav wrote:
> On 04/04/21 04:24PM, Péter Ujfalusi wrote:
>> Hi Pratyush,
>>
>> On 3/30/21 8:33 PM, Pratyush Yadav wrote:
>>> The CSI2RX subsystem uses PSI-L DMA to transfer frames to memory. It can
>>> have up to 32 threads but
Hi Pratyush,
+1 from me also to the points Tomi raised.
few minor comments on the DMAengie side.
On 3/30/21 8:33 PM, Pratyush Yadav wrote:
> TI's J721E uses the Cadence CSI2RX and DPHY peripherals to facilitate
> capture over a CSI-2 bus.
>
> The Cadence CSI2RX IP acts as a bridge between the
Hi Pratyush,
On 3/30/21 8:33 PM, Pratyush Yadav wrote:
> The CSI2RX subsystem uses PSI-L DMA to transfer frames to memory. It can
> have up to 32 threads but the current driver only supports using one. So
> add an entry for that one thread.
If you are absolutely sure that the other threads are
Hi Pierre,
On 3/26/21 11:59 PM, Pierre-Louis Bossart wrote:
> cppcheck warning:
>
> sound/soc/ti/omap-mcbsp.c:379:11: style: The if condition is the same
> as the previous if condition [duplicateCondition]
>
> if (mcbsp->irq) {
> ^
> sound/soc/ti/omap-mcbsp.c:376:11: note: First
On 3/26/21 11:59 PM, Pierre-Louis Bossart wrote:
> cppcheck warning:
>
> sound/soc/ti/omap-abe-twl6040.c:173:10: style: Variable 'ret' is
> assigned a value that is never used. [unreadVariable]
> int ret = 0;
> ^
Thanks,
Acked-by: Peter Ujfalusi
>
> Signed-off-by: Pierre-Louis
Hi Kishon,
On 2/9/21 2:02 PM, Kishon Vijay Abraham I wrote:
> bcdma_get_*() and udma_get_*() checks if bchan/rchan/tchan/rflow is
> already allocated by checking if it has a NON NULL value. For the
> error cases, bchan/rchan/tchan/rflow will have error value
> and bcdma_get_*() and udma_get_*()
Hi Kishon,
On 2/9/21 2:45 PM, Kishon Vijay Abraham I wrote:
> Hi Peter,
>
> On 09/02/21 5:53 pm, Péter Ujfalusi wrote:
>> Hi Kishon,
>>
>> On 2/9/21 11:00 AM, Kishon Vijay Abraham I wrote:
>>> bcdma_get_*() and udma_get_*() checks if bchan/rchan/tchan/rflow
Hi Kishon,
On 2/9/21 11:00 AM, Kishon Vijay Abraham I wrote:
> bcdma_get_*() and udma_get_*() checks if bchan/rchan/tchan/rflow is
> already allocated by checking if it has a NON NULL value. For the
> error cases, bchan/rchan/tchan/rflow will have error value
> and bcdma_get_*() and udma_get_*()
Hi,
On 1/24/21 9:09 AM, Christophe JAILLET wrote:
In 'dma_pool_create()', we return -ENOMEM, but don't release the resources
already allocated, as in all the other error handling paths.
Go to 'err_res_free' instead of returning directly.
Interesting that I only had error for the bcdma
Hi Pavel,
On 1/24/21 11:27 AM, Pavel Machek wrote:
From: Tony Lindgren
We can have multiple connections on a single McBSP instance configured
with audio graph card when using TDM (Time Division Multiplexing). Let's
allow that by configuring dais dynamically.
Still we have _one_ DAI per
Hi Vinod,
On 1/12/21 12:16 PM, Vinod Koul wrote:
> On 14-12-20, 10:13, Peter Ujfalusi wrote:
>> 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
Hi Vignesh,
On 1/12/21 4:14 PM, Vignesh Raghavendra wrote:
BCDMA RX channels have one flow per channel, therefore set the rflow_cnt
to rchan_cnt.
Without this patch, request for BCDMA RX channel allocation fails as
rflow_cnt is 0 thus fails to reserve a rflow for the channel.
Good catch,
Hi Tony,
On 12/30/20 10:43 AM, Tony Lindgren wrote:
> At least for 4430, trying to use the single conversion mode eventually
> hangs the thermal sensor. This can be quite easily seen with errors:
>
> thermal thermal_zone0: failed to read out thermal zone (-5)
>
> Also, trying to read the
On 11/10/2012 02:48 AM, Bryan Wu wrote:
> On Wed, Nov 7, 2012 at 3:42 AM, Peter Ujfalusi wrote:
>> Update the driver to use the new API for requesting pwm so we can take
>> advantage of the pwm_lookup table to find the correct pwm to be used for the
>> LED functionality.
>> If the devm_get_pwm
On 11/10/2012 02:48 AM, Bryan Wu wrote:
On Wed, Nov 7, 2012 at 3:42 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
Update the driver to use the new API for requesting pwm so we can take
advantage of the pwm_lookup table to find the correct pwm to be used for the
LED functionality.
If the
On 11/08/2012 01:29 PM, Grazvydas Ignotas wrote:
>> But I want to note that I'm currently trying to clean up the mess around
>> twl-core. In my view we have quite a bit of redundancy in there. The PWM A/B
>> is for driving the LED A/B outputs. We should have only these modules for
>> PWM/LED in
On 11/08/2012 01:29 PM, Grazvydas Ignotas wrote:
But I want to note that I'm currently trying to clean up the mess around
twl-core. In my view we have quite a bit of redundancy in there. The PWM A/B
is for driving the LED A/B outputs. We should have only these modules for
PWM/LED in twl-core:
On 11/07/2012 07:12 PM, Grazvydas Ignotas wrote:
>> +static int twl4030_pwmled_config(struct pwm_chip *chip, struct pwm_device
>> *pwm,
>> + int duty_ns, int period_ns)
>> +{
>> + int duty_cycle = (duty_ns * TWL4030_LED_MAX) / period_ns;
>> + u8 on_time;
>>
On 11/07/2012 06:50 PM, Grazvydas Ignotas wrote:
>> +static int twl4030_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
>> +{
>> + int ret;
>> + u8 val;
>> +
>> + ret = twl_i2c_read_u8(TWL4030_MODULE_INTBR, , TWL4030_GPBR1_REG);
>> + if (ret < 0) {
>> +
On 11/07/2012 06:50 PM, Grazvydas Ignotas wrote:
+static int twl4030_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ int ret;
+ u8 val;
+
+ ret = twl_i2c_read_u8(TWL4030_MODULE_INTBR, val, TWL4030_GPBR1_REG);
+ if (ret 0) {
+
On 11/07/2012 07:12 PM, Grazvydas Ignotas wrote:
+static int twl4030_pwmled_config(struct pwm_chip *chip, struct pwm_device
*pwm,
+ int duty_ns, int period_ns)
+{
+ int duty_cycle = (duty_ns * TWL4030_LED_MAX) / period_ns;
+ u8 on_time;
+ u8
Hi Mike,
On 10/29/2012 06:30 PM, Mike Turquette wrote:
> Peter,
>
> The patch looks good to me. To be clear, you wan this to go through
> clk-next or the mfd tree for avoiding conflicts?
clk-next is the best place for it I think. The MFD part to register the device
can still wait till we have
Hi Mike,
On 10/29/2012 06:30 PM, Mike Turquette wrote:
Peter,
The patch looks good to me. To be clear, you wan this to go through
clk-next or the mfd tree for avoiding conflicts?
clk-next is the best place for it I think. The MFD part to register the device
can still wait till we have ccf
Hi Dmitry,
On 06/15/2012 12:22 PM, Peter Ujfalusi wrote:
> Hello,
>
> Convert the twl4030, twl6040 vibra drivers to use devm_ at probe time to clean
> up the code a bit.
> The twl6040-vibra driver needed bigger change since the ordering of the
> initialization was not correct.
Would it be
Hi Dmitry,
On 06/15/2012 12:22 PM, Peter Ujfalusi wrote:
Hello,
Convert the twl4030, twl6040 vibra drivers to use devm_ at probe time to clean
up the code a bit.
The twl6040-vibra driver needed bigger change since the ordering of the
initialization was not correct.
Would it be possible to
On 10/08/2012 07:35 PM, Tony Lindgren wrote:
> - omap-dma.c and omap-pcm.c can test the arch locally as
> omap1 and omap2 cannot be compiled together because of
> conflicting compiler flags
> sound/soc/omap/omap-pcm.c |9 +++--
Tony: is this going to be included in 3.7?
On 10/08/2012 07:35 PM, Tony Lindgren wrote:
- omap-dma.c and omap-pcm.c can test the arch locally as
omap1 and omap2 cannot be compiled together because of
conflicting compiler flags
sound/soc/omap/omap-pcm.c |9 +++--
Tony: is this going to be included in 3.7?
29 matches
Mail list logo
