lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 15 Jun 2014 16:48:58 +0200
From:	Boris BREZILLON <boris.brezillon@...e-electrons.com>
To:	jjhiblot@...phandler.com,
	Thierry Reding <thierry.reding@...il.com>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	David Airlie <airlied@...ux.ie>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Lee Jones <lee.jones@...aro.org>
CC:	Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-pwm@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v2 1/7] mfd: add atmel-hlcdc driver

Hello JJ,

On 15/06/2014 10:53, Jean-Jacques Hiblot wrote:
> On 06/09/2014 06:04 PM, Boris BREZILLON wrote:
>> The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
>> family or sama5d3 family) exposes 2 subdevices:
>> - a display controller (controlled by a DRM driver)
>> - a PWM chip
>>
>> Add support for the MFD device which will just retrieve HLCDC clocks and
>> create a regmap so that subdevices can access the HLCDC register range
>> concurrently.
>>
>> Signed-off-by: Boris BREZILLON <boris.brezillon@...e-electrons.com>
>> ---
>>  .../devicetree/bindings/mfd/atmel-hlcdc.txt        |  41 ++++++++
>>  drivers/mfd/Kconfig                                |  11 ++
>>  drivers/mfd/Makefile                               |   1 +
[...]
>> +	memset(&config, 0, sizeof(config));
>> +	config.reg_bits = 32;
>> +	config.val_bits = 32;
>> +	config.reg_stride = 4;
>> +	config.max_register = (resource_size(res) / 4) - 1;
>> +	hlcdc->regmap = devm_regmap_init_mmio_clk(dev, "periph_clk", regs,
>> +						  &config);
> I don't think it's necessary to use "periph_clk" here. This clock will
> always be running because the HLCDC needs it to work (it's not just an
> interface clock). In the end it's just some extra work for each register
> access.

Yes, I thought about removing this clk from regmap registration too (for
the exact same reason: avoiding extra enable/disable work when accessing
registers), but ATM I do not prepare/enable periph_clk in the hlcdc-pwm
driver, this means the regmap won't work until the hlcdc-dc driver has
probed the display controller device.

How about preparing/enabling the periph_clk in the MFD device, so that
PWM and Display Controller subdevices won't have to bother about this
clk, and the regmap will work as expected ?
Or, should we just prepare/enable the periph clock in each subdevices ?


Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists