lkml.org 
[lkml]   [2021]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1/3] soundwire: bus: clear bus clash interrupt before the mask is enabled
From
Date


On 2/1/21 4:38 AM, Vinod Koul wrote:
> On 01-02-21, 15:58, Vinod Koul wrote:
>> On 26-01-21, 16:37, Bard Liao wrote:
>
>>> struct sdw_master_prop {
>>> u32 revision;
>>> @@ -421,8 +422,11 @@ struct sdw_master_prop {
>>> u32 err_threshold;
>>> u32 mclk_freq;
>>> bool hw_disabled;
>>> + u32 quirks;
>>
>> Can we do u64 here please.. I dont know where we would end up.. but
>> would hate if we start running out of space ..
No objection.

> Also, is the sdw_master_prop right place for a 'quirk' property. I think
> we can use sdw_master_device or sdw_bus as this seems like a bus
> quirk..?

It's already part of sdw_bus

struct sdw_bus {
struct device *dev;
struct sdw_master_device *md;
unsigned int link_id;
int id;
struct list_head slaves;
DECLARE_BITMAP(assigned, SDW_MAX_DEVICES);
struct mutex bus_lock;
struct mutex msg_lock;
int (*compute_params)(struct sdw_bus *bus);
const struct sdw_master_ops *ops;
const struct sdw_master_port_ops *port_ops;
struct sdw_bus_params params;
struct sdw_master_prop prop;

The quirks could be set by a firmware property, and it seems logical to
add them at the same place where we already have properties defined in
firmware, no? That way all the standard, vendor-specific and quirks are
read or added in the same place.

the sdw_master_device isn't a good place for quirks IMHO, it's a very
shallow software-only layer without any existing ties to the hardware
definition.

\
 
 \ /
  Last update: 2021-02-01 19:18    [W:0.101 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site