On 4/8/21 12:26 PM, Shubhrajyoti Datta wrote:
> On Sun, Mar 7, 2021 at 1:50 AM Rob Herring wrote:
>>
>> On Wed, Feb 24, 2021 at 06:40:40PM +0530, Shubhrajyoti Datta wrote:
>>> Add the devicetree binding for the xilinx clocking wizard.
>>>
>>> Signed-off-by: Shubhrajyoti Datta
>>> ---
>>> v6:
Hi Miquel,
On 1/21/21 3:39 PM, Miquel Raynal wrote:
> Hi Shubhrajyoti,
>
> Shubhrajyoti Datta wrote on Wed, 4 Nov
> 2020 20:36:40 +0530:
>
>> In the thread [1] Greg suggested that we move the driver
>> to the clk from the staging.
>> Add patches to address the concerns regarding the fractional
Hi Stephen,
First of all sorry for very slow response. I didn't get this email even
xilinx alias is in CC. Something is really fishy here.
On 12/13/20 6:36 AM, Stephen Boyd wrote:
> Quoting Shubhrajyoti Datta (2020-11-04 07:06:40)
>>
>> Shubhrajyoti Datta (7):
>> dt-bindings: add documentation
Hi Stephen,
On 04. 11. 20 16:06, Shubhrajyoti Datta wrote:
>
> In the thread [1] Greg suggested that we move the driver
> to the clk from the staging.
> Add patches to address the concerns regarding the fractional and
> set rate support in the TODO.
>
> The patch set does the following
> - Trivi
On 11.5.2018 09:58, James Kelly wrote:
> Hi Michal
>
> On 11 May 2018 at 16:06, Michal Simek wrote:
>
>> On 7.5.2018 03:20, James Kelly wrote:
>>> The CCF clock providers that are currently used by the driver are not
>>> capable of supporting the Clock
Hi James,
On 11.5.2018 09:31, James Kelly wrote:
> Hi Michal,
>
> On 11 May 2018 at 16:04, Michal Simek wrote:
>
>> Hi,
>>
>> On 7.5.2018 03:20, James Kelly wrote:
>>> Add a description for how the Xilinx Clocking Wizard IP works to guide
>>>
Hi,
On 7.5.2018 03:20, James Kelly wrote:
> Add a description for how the Xilinx Clocking Wizard IP works to guide
> subsequent patches.
>
> Signed-off-by: James Kelly
> ---
> .../clocking-wizard/clk-xlnx-clock-wizard.c| 52
> ++
> 1 file changed, 52 insertions(+)
>
On 7.5.2018 03:20, James Kelly wrote:
> The CCF clock providers that are currently used by the driver are not
> capable of supporting the Clocking Wizard IP register interface for
> fractional ratios, nor are they able to enforce constraints require to
> ensure the PLL will always lock.
>
> None o
On 7.5.2018 03:20, James Kelly wrote:
> Replace existing CCF clock providers with new clock provider that can
> be enhanced to meet our needs.
>
> AXI clock prepare/enable/disable/unprepare is now managed by regmap APIs.
>
> Unregistering of clk instances now handled by devm APIs.
>
> Drop warni
On 7.5.2018 03:20, James Kelly wrote:
> Provide initial support for CCF clk_set_rate API on all clock components.
>
> Clock consumers that want to set the first divider or PLL clock will need
> to use clk_get_parent on one of the output clocks as there is no support
> for CLK_SET_RATE_PARENT yet.
On 7.5.2018 03:20, James Kelly wrote:
> Add support for the clk_round_rate API to our CCF clock provider.
>
> Signed-off-by: James Kelly
> ---
> .../clocking-wizard/clk-xlnx-clock-wizard.c| 107
> +
> 1 file changed, 107 insertions(+)
>
> diff --git a/drivers/stagin
On 7.5.2018 03:20, James Kelly wrote:
> Publish clock divider/multiplier ratios and flags specific to our
> clock provider implementation as these are not available via the
> debugfs entries provided by the common clock framework.
>
> Signed-off-by: James Kelly
> ---
> .../clocking-wizard/clk-xl
On 7.5.2018 03:20, James Kelly wrote:
> Replace existing CCF clock providers with new clock provider that can
> be enhanced to meet our needs.
>
> AXI clock prepare/enable/disable/unprepare is now managed by regmap APIs.
>
> Unregistering of clk instances now handled by devm APIs.
>
> Drop warni
On 02/17/2015 08:17 PM, Pavel Machek wrote:
> On Tue 2015-02-17 11:07:53, Rob Landley wrote:
>>
>>
>> On 02/15/2015 04:40 PM, Pavel Machek wrote:
>>> On Wed 2015-01-21 13:27:00, Jason Gunthorpe wrote:
On Wed, Jan 21, 2015 at 06:33:12PM +0200, Pantelis Antoniou wrote:
My point is that the
On 01/11/2015 10:31 PM, Pavel Machek wrote:
> On Sun 2015-01-11 21:58:00, Konrad Zapalowicz wrote:
>> On 01/11, Pavel Machek wrote:
>>> On Sun 2015-01-11 17:24:26, Konrad Zapalowicz wrote:
On 01/11, atull wrote:
> On Sat, 10 Jan 2015, Konrad Zapalowicz wrote:
>
>> On 01/06, at...@o
On 01/12/2015 09:45 AM, Pavel Machek wrote:
> On Sun 2015-01-11 10:29:00, atull wrote:
>> On Sat, 10 Jan 2015, Pavel Machek wrote:
>>
>>> On Sat 2015-01-10 10:10:51, Pantelis Antoniou wrote:
Hi Pavel,
> On Jan 9, 2015, at 22:56 , Pavel Machek wrote:
>
> On Fri 2015-01-09 13:1
Hi Greg,
On 12/18/2014 11:29 PM, at...@opensource.altera.com wrote:
> From: Alan Tull
>
> Dropping the changes to socfpga DTS and defconfig from this
> patch set.
>
> Kernel doc fixes and other minor fixes as listed in the patches.
>
> Alan
>
> Alan Tull (4):
> doc: add bindings document fo
re tested for NULL before being
> + * called, so leaving them out is fine.
> + */
> +struct fpga_manager_ops {
> + enum fpga_mgr_states (*state)(struct fpga_manager *mgr);
> + int (*reset)(struct fpga_manager *mgr);
> + int (*write_init)(struct fpga_manager *mgr);
> + int (*write)(struct fpga_manager *mgr, const char *buf, size_t count);
> + int (*write_complete)(struct fpga_manager *mgr);
> + void (*fpga_remove)(struct fpga_manager *mgr);
> + int (*suspend)(struct fpga_manager *mgr);
> + int (*resume)(struct fpga_manager *mgr);
> +};
> +
> +/**
> + * enum fpga_mgr_states - fpga framework states
> + * @FPGA_MGR_STATE_UNKNOWN: can't determine state
> + * @FPGA_MGR_STATE_POWER_OFF: FPGA power is off
> + * @FPGA_MGR_STATE_POWER_UP: FPGA reports power is up
> + * @FPGA_MGR_STATE_RESET: FPGA in reset state
> + * @FPGA_MGR_STATE_FIRMWARE_REQ: firmware request in progress
> + * @FPGA_MGR_STATE_FIRMWARE_REQ_ERR: firmware request failed
> + * @FPGA_MGR_STATE_WRITE_INIT: preparing FPGA for programming
> + * @FPGA_MGR_STATE_WRITE_INIT_ERR: Error during WRITE_INIT stage
> + * @FPGA_MGR_STATE_WRITE: writing image to FPGA
> + * @FPGA_MGR_STATE_WRITE_ERR: Error while writing FPGA
> + * @FPGA_MGR_STATE_WRITE_COMPLETE: Doing post programming steps
> + * @FPGA_MGR_STATE_WRITE_COMPLETE_ERR: Error during WRITE_COMPLETE
> + * @FPGA_MGR_STATE_OPERATING: FPGA is programmed and operating
> + */
> +enum fpga_mgr_states {
> + FPGA_MGR_STATE_UNKNOWN,
> + FPGA_MGR_STATE_POWER_OFF,
> + FPGA_MGR_STATE_POWER_UP,
> + FPGA_MGR_STATE_RESET,
> +
> + /* write sequence */
> + FPGA_MGR_STATE_FIRMWARE_REQ,
> + FPGA_MGR_STATE_FIRMWARE_REQ_ERR,
> + FPGA_MGR_STATE_WRITE_INIT,
> + FPGA_MGR_STATE_WRITE_INIT_ERR,
> + FPGA_MGR_STATE_WRITE,
> + FPGA_MGR_STATE_WRITE_ERR,
> + FPGA_MGR_STATE_WRITE_COMPLETE,
> + FPGA_MGR_STATE_WRITE_COMPLETE_ERR,
> +
> + FPGA_MGR_STATE_OPERATING,
> +};
> +
> +/**
> + * struct fpga_manager - fpga manager structure
> + * @name: name of low level fpga manager
> + * @dev: fpga manager device
> + * @list: entry in list of all fpga managers
> + * @lock: lock on calls to fpga manager ops
> + * @state: state of fpga manager
> + * @image_name: name of fpga image file if any
> + * @mops: pointer to struct of fpga manager ops
> + * @priv: low level driver private date
> + */
> +struct fpga_manager {
> + const char *name;
> + struct device dev;
> + struct list_head list;
> + struct mutex lock; /* lock on calls to ops */
> + enum fpga_mgr_states state;
> + char *image_name;
> +
> + const struct fpga_manager_ops *mops;
> + void *priv;
> +};
> +
> +#define to_fpga_manager(d) container_of(d, struct fpga_manager, dev)
> +
> +int fpga_mgr_firmware_write(struct fpga_manager *mgr, const char
> *image_name);
> +int fpga_mgr_write(struct fpga_manager *mgr, const char *buf, size_t count);
> +int fpga_mgr_name(struct fpga_manager *mgr, char *buf);
> +int fpga_mgr_reset(struct fpga_manager *mgr);
> +int fpga_mgr_register(struct device *pdev, const char *name,
> + const struct fpga_manager_ops *mops, void *priv);
> +void fpga_mgr_remove(struct platform_device *pdev);
> +
> +#endif /*_LINUX_FPGA_MGR_H */
>
Signed-off-by: Michal Simek
Thanks,
Michal
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
gt;> of FPGA in Altera SoCFPGA parts.
>>
>> Signed-off-by: Alan Tull
>> Acked-by: Michal Simek
>> ---
>> v2: fpga_manager struct now contains struct device
>> fpga_manager_register parameters now take device
>>
>> v3: skip a version to align versio
On 12/18/2014 09:46 PM, atull wrote:
> On Thu, 18 Dec 2014, Michal Simek wrote:
>
>> Hi Alan,
>>
>> first of all - there are these kernel-doc warnings.
>>
>> Info(drivers/staging/fpga/fpga-mgr.c:37): Scanning doc for
>> fpga_mgr_low_level_state
>>
On 12/18/2014 09:59 PM, atull wrote:
> On Thu, 18 Dec 2014, Michal Simek wrote:
>
> Hi Michal,
>
>>> +
>>> + /* Write out remaining non 32-bit chunks. */
>>> + switch (count) {
>>> + case 3:
>>> + socfpga_fpga_data_writel(
Hi Alan,
first of all - there are these kernel-doc warnings.
Info(drivers/staging/fpga/fpga-mgr.c:37): Scanning doc for
fpga_mgr_low_level_state
Warning(drivers/staging/fpga/fpga-mgr.c:43): No description found for return
value of 'fpga_mgr_low_level_state'
Info(drivers/staging/fpga/fpga-mgr.c:
NOWN,
> +};
> +
> +static enum fpga_mgr_states socfpga_fpga_ops_state(struct fpga_manager *mgr)
> +{
> + struct socfpga_fpga_priv *priv = mgr->priv;
> + enum fpga_mgr_states ret;
> + u32 state;
> +
> + state =
On 12/17/2014 06:32 PM, Greg KH wrote:
> On Wed, Dec 17, 2014 at 10:54:49AM -0600, at...@opensource.altera.com wrote:
>> From: Alan Tull
>>
>> Enable FPGA manager for Altera socfpga.
>>
>> Signed-off-by: Alan Tull
>> ---
>> v5: s/CONFIG_FPGA_MGR_ALTERA/CONFIG_FPGA_MGR_SOCFPGA/
>> ---
>> arch/arm
d CONFIG_B4860G100, now I think I might better to update
>> Kconfig to include CONFIG_B4860G100.
>>
>> Greg, what do you think? Any harm to add custom board CONFIG* to
>> staging Kconfig? Let me know.
>
> Let's see what it would look like and we can go from there.
25 matches
Mail list logo
